As a related i18n topic, for our Bahmni deployments (including endtb) we want to be able to use Transifex to translate Concepts and then incorporate those translations back into our deployment.
From what we understand of the current design of Bahmni, this will involve ensuring that the short name of a Concept in a given locale has the text that we want to display to the end user for a particular Concept.
We are expecting to adopt the following process:
For all of the existing concepts, export a JSON map of “concept uuid”: “concept english short name”
Upload this JSON resource to Transifex and get it translated
Export the various translated resources for these in JSON format
Update the concept dictionary such that appropriate short names exist in each locale with appropriate text
Ideally, in order to facilitate this process, there would be a standard location within Bahmni config where these JSON files could live. For example:
Would you be on board with reserving the “openmrs / i18n / concepts” directory for this purpose? For now, reserving it for this type of use is all that is needed, so we can put things there without possible conflicts. Or do you have an alternative suggestion / recommendation?
Down the road, I’d love for Bahmni to read from this folder on startup and automatically apply any translations from here into the concept dictionary. This way, we can have a single process for managing translations between Transifex and the Bahmni i18n configuration.
Hi Mike,
The management of concepts used for configuring Bahmni for i18n is not
required. The expectation is that the configurations related to concept
names done in Json files will always be in English. It means that the
database that we use should always contain all the concepts in locale en
and the translations should always be against it.
@bharatak, I believe that @mseaton is talking about the need to translate concepts, not to configure the system.
I.e. he wants a workflow where a translator can go into Transifex and “do the Spanish translation” (where under the hood this actually means translating both the UI and the concept dictionary).
My own opinion is that in the long run we need a better approach to managing concepts in an external service (like OCL), and most of the translation should happen there. But given the current state of things, letting concept translations happen via transifex (instead of the OpenMRS admin UI) makes sense.
(The only downside is that the translator would have less contextual information when doing the translation, e.g. they don’t see the concept’s datatype, class, etc. In practice, translators for a given implementation probably don’t care about this.)
Hi,
Slightly slow on emails.
>> Would you be on board with reserving the “openmrs / i18n / concepts”
directory for this purpose?
Yes. Please go ahead.
>> Down the road, I’d love for Bahmni to read from this folder on startup
and automatically apply any translations from here into the concept
dictionary.
On startup or via a regular scheduled job. But yes this sounds good too.
As with the rest of the resources, we have not yet configured our CI server to automatically pull in reviewed translations. We will update after we have introduced that step of the process.
So, the team could start translating now, but I can’t say exactly when we’ll start pulling the translations in (for the normal resources) and I can’t promise exactly when the “automatically apply translation to the concept dictionary” story will get done.