cht-conf
cht-conf copied to clipboard
Ability to backup and delete custom translations
It would be useful to be able to backup and remove custom translations using medic-conf, similar to how we upload-custom-translations
.
Backup would be useful to have some record of translations in case we overwrite user edited one, and perhaps more importantly to know which fields have been edited in the app and bring them into the custom translations in the config. Delete would be useful if we want to remove any labels edited in the app, which may have been done by erroneously. This would also be helpful when instances are cloned from one another and we want to return to a clean set of translations.
I think you can already back up translations from the UI, so that seems like it would be useful to potentially add to medic-conf.
Can you explain the use case / workflow you are imagining for each of these proposed features? I'd like to know how you are expecting them to be used and when.
Here are a couple user stories:
- As a tech lead I want to download translations edited in the app to save them with my config in github.
- As a tech lead I want to delete the translations edited in the UI before uploading a new set so that I know exactly what all the translations are when setting up a new instance or pushing a config to an instance .
Can you provide more context here? I am wondering how these fit into our current process for managing translations and for setting up new instances. I think I need to better understand the problem being solved here as I haven't seen this come up before. Can you elaborate?
When new instances are set up, especially for test purposes, we often use a clone of an existing instance. It is also possible for configurable components to be edited in the UI without the person managing the configuration knowing. In both cases, a configurer needs to know that they can: 1) remove/overwrite any configuration, and 2) backup any changes made via UI so it can be saved in github.
For 2, even if this process is not automatic we need to at least be able to tell that something was changed. For app-settings and forms we can back them up using CLI and do a diff. For resources we can manually see which have been changed on an instance, which is cumbersome, but possible. For Translations it is not possible to know which custom translation changes were made because they are lumped in together with all the other app labels. Downloading the translations from the UI does not distinguish the medic-webapp labels from custom labels.
Here is a table outlining which components can be backed up and inspected:
component | upload via CLI | edit via UI | backup via CLI | backup via UI | inspect changes via UI |
---|---|---|---|---|---|
app-settings |
yes | yes | yes | no | no |
forms |
yes | yes | yes | no | yes |
resources |
yes | yes | no | no | yes |
translations |
yes | yes | no | no | no |
Ideally we would have a yes
for all the "backup via CLI", and then "backup via UI", but the most critical to start with would be "backup via CLI" for translations since those cannot reasonably be inspected. Otherwise we:
- unknowingly carry over translations
- don't save in GitHub translations that were edited in the UI