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.
@dkayiwa and @ibacher we are getting more and more collaborators adding translations via Transifex (e.g. Portuguese, Chinese!) - can we please set up auto-pull-in to the O3 RefApp dev3??
So I’ve finished updating the configurations for Transifex for the chart, patient management, and core. This means that all translation updates for these repos (and home) must be done through Transifex. You should be able to create a free account on Transifex if you want to contribute translations. We would be extremely happy to have better translations and more language coverage!How this works:
All translatable text is provided in packages with keys and the default English string. This is because the majority of our contributors speak English, and we want to have the source in a consistent language.
On each merge, the latest English strings are uploaded to Transifex, which will track how many string have been translated into each language.
Daily, each repo has a job that will ask Transifex for any changes to non-English translation files, and pull these into a PR.
We will monitor these PRs and merge as appropriate; depending on how things go, we may re-assess having a PR step at all and simply auto-commit the translations, but for the immediate future, a review step seems prudent so we don’t eliminate the hard work that so many people have put into our current set of translations.
If you encounter any issues with this setup or have any questions, please feel free to reply in this thread or ask on Slack. Thank you all for your wonderful work!
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.