Support translating AMPATH Form Names via ampathformtranslations domain

[ibacher]

E.g.,

{
    "uuid": "6381a458-9504-418a-b3fe-2e023e6d2550",
    "form": "Test Form 1",
    "form_name_translation": "Formulaire de Teste",
    "description": "French Translations for 'Test Form 1'",
    "language": "fr",
    "translations": {
      "Page 1": "Première page",
      "Section 1": "Première section",
      "Height": "Taille"
    }
}

Implementation-wise, this translation should override the display string for the form, similar to how other domains do this.

[Ruhanga]

Hi @ibacher, not sure I clearly understand the goal here. IMO I'd think form_name_translation rather gets added to translations such that the frontend consuming this file is responsible for the display. Could you explain a little more how the display is consumed?

[ibacher]

@Ruhanga Basically, form_name_translation needs to override the value shown here:

At that point, the frontend will not have loaded either the actual form JSON or the translations JSON. It's just a request to the form endpoint to get all the forms. Basically, we just want to override the REST API's display property for the current locale.

If we force the frontend to do this processing, we force it to make:

1. A request to get the forms
2. A request to get the translations for the forms
3. Parse the JSON for each for and find the form_name_translation

While each of those three steps is relatively fast, the overall effect is a massive performance hit (even imagining, f/e, a instance with 20 forms, that's 21 HTTP requests to display.... table).

[ibacher]

Closed via #234

[rbuisson]

Hi @Ruhanga , @ibacher should we update also the README? https://github.com/mekomsolutions/openmrs-module-initializer/blob/master/readme/ampathformstranslations.md to reflect this addition?

[ibacher]

Indeed, we should...

[mks-d]

@ibacher is this still current or we can close this issue?

[ibacher]

This is done.