cht-conf icon indicating copy to clipboard operation
cht-conf copied to clipboard

Ability to backup and delete custom translations

Open abbyad opened this issue 6 years ago • 4 comments

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.

abbyad avatar Mar 22 '18 18:03 abbyad

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.

sglangevin avatar Mar 22 '18 20:03 sglangevin

Here are a couple user stories:

  1. As a tech lead I want to download translations edited in the app to save them with my config in github.
  2. 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 .

abbyad avatar Mar 23 '18 12:03 abbyad

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?

sglangevin avatar Mar 23 '18 17:03 sglangevin

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:

  1. unknowingly carry over translations
  2. don't save in GitHub translations that were edited in the UI

abbyad avatar Mar 29 '18 14:03 abbyad