I’ve recently been asked, “How can our org translate O3 app string content? How do we use Transifex to help with this?”
This is a great question, since any organization needing to translate the O3 EMR will run into this.
Here is my understanding: tl;dr: The translation files will have to be pulled from Transifex and committed into the code directly, for each repo.
Transifex Setup: Ensure the O3 repos you need are included in the OpenMRS Org Transifex project (e.g. you can see esm-patient-management is here, esm-patient-chart is here, etc)
Complete Translation in Transifex UI: Ensure your translation team goes through the UI to translate each repo’s strings (e.g. here at this link we see both the complete & incomplete french translations for the Registration App)
Manual, Simple Workflow:
Export JSON from Transifex: In the left navigation, click Resources for the Repo, then click the language you want, and click “Download for use” from the Resources modal that popped up.
Upload JSON into the repo’s esm-NAME-app/translations/ directory: E.g. this example of JSON string translations uploaded for the active visits app
Then: The strings should be translated in the UI when the user switches their locale.
OR
4. Automated Workflow: This can also be done by using the CLI Transifex client and running tx pull -l fr (to get the fr locale for instance) and commit the changes.
Ideally, it should be our CD doing that though. @mksrom recalls that Brandon had set up something a while back with Bamboo, maybe this Build, maybe we can reuse that? @dkayiwa what would we need to do in order to set things up so that translation work done in Transifex is automatically pulled into the O3 RefApp?
@frederic.deniger which approach do you think you’ll want to take? #3 seems surprisingly easy, just manual work to go through the export/import process.
Hello @grace
thanks for the feedback.
IMHO, the manual worklow #3 would be the good approach as we won’t modify these translations every day. Of course, if the Automated workflow can be implemented it will be better but it won’t be a game changer ( and maybe we will spend more time on maintaining this CI than the manual approach).
I thought Transifex had the ability to publish changes to GitHub. If we could leverage that capability, it would allow us to manage translations in one place (i.e., any repo set up in Transifex would get updates without needing to maintain a separate list in Bamboo).
This sounds simple… am I missing something? @dkayiwa what would be the approx amount of time this would take you to set up? (I tried doing it myself following this documentation but I don’t know if I have all the right admin permissions.)
And is there any reason not to automatically grab translations out of Transifex and add them to our O3 repos?
@dkayiwa yes - seems like with GitHub Actions we can kick off translation updates directly from Transifex on a scheduled basis. Ian pointed out to me today that it makes sense to do it there instead of in Bamboo, because all our O3 frontend stuff is already happening via Github Actions.
In fact, the timing right now seems perfect, because @frederic.deniger’s team has a group of people actively doing French translations right now using the Transifex UI within the OpenMRS Org.
This flow would reduce the turnaround time for those translators to also review their work: They could almost immediately go and check in dev3 (if their own distro can’t be kept that closely up to date). This helps address one of the hardest parts of accurate translations: Making sure the translations are contextually appropriate. Sounds win-win!!
@dkayiwa would you be up for hooking this pipeline up?
This would also mean that efforts to expand our network of community volunteer Translators could really have impressive, quick impact.
The only concern might be the fact that this means anything done in the OpenMRS org on Transifex would be auto-submitted. We already have a past Bamboo job that blanketly approves all translations. Right now, auto-approving is the only scaleable solution we have. Or, we could turn-off the review setting/requirement in our Transifex org overall. @burke have there been any hard lessons learned about this in our past?
As long as we make sure that we’ve updated the data on Transifex with the latest copies from the repos before we turn on the auto-pull, no. (Basically, just make sure we don’t clobber the various lovely translations we have so far).
@dkayiwa you tell me? I genuinely don’t know. From a quick glance at that CI project looks like it hasn’t successfully run since March (I don’t know why) and doesn’t look like it contains any O3 stuff at all.
I don’t mean to suggest we need to destroy anything; it would just be great if the O3 RefApp was automatically updated based on work done in Transifex.
Transifex finally sunset their old API and client which is what that job builds. We need to convert the O2 repositories to the new configuration format (@mksrom already did this for O3) and convert that job to using the Docker CLI.
I genuinely don’t know. From a quick glance at that CI project looks like it hasn’t successfully run since March (I don’t know why) and doesn’t look like it contains any O3 stuff at all.