I’d like to understand a bit better the process by which we expect Bahmni to be translated, both within the core product as well as within implementation-specific content. I’m currently motivated around the endTB project, but the question is more general as well for any Bahmni deployment.
Currently, the standard approach for translation within OpenMRS is via Transifex. For community-supported modules, this is via the “OpenMRS” project in Transifex, which contains resources for each module beneath each language. You can see some wiki documentation here, and see the en_US resources here. Organizations can also have Transifex projects. For example, you can see the en_US for many of the PIH modules here.
I think it would be useful to discuss whether we could follow a similar approach for Bahmni, or if you have other plans. Some specific thoughts:
Allow the implementation community to translate the core Bahmni product by creating a bahmni project in Transifex and opening it up for contributions.
Add in the necessary steps to your processes to pull in the latest translations from Transifex when you create new build artifacts.
Add additional resources beyond the core product for implementations that you support directly and are providing content for (eg. endTB), and ensure these are pulled into the builds as appropriate
Allow for implementations to manage their own translations via Transifex for their own content (or to override the default Bahmni translations), and support a well documented process to enable this.
These are just some initial ideas. I’m interested in hearing others thoughts, or if you have an alternative approach that you are working towards that will enable similar capabilities in Bahmni.
I would definitely recommend Transifex as the default approach for translations.
We were able to use it very well at PIH on the Mirebalais project at the peak of dev effort, when we had a combination of volunteer and paid translators translating to French and Haitian Creole.
For the Reference Application we’ve kind-of sort-of tried to use Transifex, but not so well, because we haven’t actually gotten it incorporated into the module release process. I think the is purely due to poor organization, which won’t be a problem for the Bahmni team.
(There may be other competitive tools that are better, but Transifex is definitely good enough for our use case.)
Hi Mike,
Completely agree and thanks for providing the use cases too, they would be
helpful.
It makes sense for us to prioritise this sooner than later. Currently it
looks like we should be able to have this setup and running in Q2 this year.
Inspired by some conversation about translating the Reference Application, I had a thought: we should consider doing the Bahmni translations inside the OpenMRS organization in Transifex, rather than setting up our own.
Basically, translation isn’t a core competency of the Bahmni team, and this kind of function will work better in a crowdsourced way with a broader audience. And Transifex also learns/suggests translations across multiple resources in one project, which might help.
(Of course OpenMRS would need to set some ground rules about what can be added to the OpenMRS Transifex account.)
I wanted to ping on this thread given what I have just started before it gets put into use. Essentially, from my comment above:
In the absence of Bahmni setting up the basic foundation of this, but the need for these translations to happen now, they will start to evolve on their own in an “unofficial” Bahmni Transifex project, which may be less than ideal.
For endTB, I just created a new “endtb” project under the “pih” organization in Transifex, and uploaded each of the locale_en.json files as new resources, as can be found here:
Can the Bahmni team consider whether they would prefer for this work to happen in an alternative Transifex organization/project now that is opened up to the implementations to contribute to and manage directly? Or whether it is preferable to pilot this approach in the pih/endtb project which could be pulled into a new Bahmni Transifex project later on this year?
I could see the merits of either approach, but we wanted to confirm before we start creating processes based on the above.
After thinking about this a bit, we have decided to try doing Bahmni translations under the OpenMRS organization in Transifex. This is a first-time experiment, but we’re curious/excited to see how it goes. (Some thoughts here.)
Note: we still have to integrate this into our build pipelines, and define the review process, so any translations you make now won’t be pulled in immediately. We’ll comment on this thread again when that is set up.
This is great! Thanks for getting this set up and for the Bahmni team supporting the translation process in this way.
The big remaining area of translation as discussed on parallel thread is for Concept short names. My initial proposal (for endTB) is to:
Have an endtb-config/openmrs/i18n/concepts folder, which contains CSVs (Magento CSV format per Transifex)
Manage this in Transifex with a resource name of “endTB Concepts”
Whenever the endTB database is updated (or in subsequent changesets), the locale_en.csv file is updated to reflect this
In a later step (not yet defined, might be manual at first), the localized concept names can be applied to the DB as new or updated concept names in order to translate the system.
Yesterday, I threw together a quick first pass for doing this which can be seen in this pull request:
Thoughts on this and in getting this into Transifex as another “endTB” resource?
I approve of using Transifex to do this translations
But instead of CSV, let’s use the Java messages.properties format that OpenMRS has been standardizing on for localizing metadata (e.g. ui.i18n.Concept.name.<uuid> like this example, as supported by the REST and UI Framework modules)
once this is merged into the codebase, I will create a resource for it in Transifex
I don’t have an opinion about the best way to apply those translations to concepts in the database. (In the long run I hope Bahmni can leverage OCL for concept management, but for endTB in the short term your suggestion sounds right)
We have been tasked to implement a custom EMR and ERP solution for a public hospital system in Honduras. We chose Bahmni as our core system and plan on extending it to meet the hospital’s and country’s specific needs. One of our first tasks as a team is to complete the translation from English to Spanish and be sure that everything is thoroughly reviewed. We hope to put a sizable dent into the translation effort and make OpenMRS and Bahmni more relevant for Spanish speaking countries. I’m confident we can do this since my team is 100% fluent in both English and Spanish.
We found out, by reading at these forms, that Transifex would be the best approach for translations. From that, I have a question, which of the OpenMRS projects found on Transifex should we use to translate Bahmni on our implementation? OpenMRS or Bahmi?
The translation files used by the OpenMRS and Bahmni applications are completely independent of each other. In order to translate the Bahmni UI (e.g. what you see here) you need to translate the files within the Bahmni project in transifex: https://www.transifex.com/openmrs/bahmni/.
If you also want to translate the underlying OpenMRS application, whose UI Bahmni uses for admin purposes, this is not currently enabled in Transifex, but we should be able to turn this on quickly. (Someone was asking for this in July and it looks like I failed to follow up.) I will try to do this soon.
But you can start by translating and reviewing the resources in the Bahmni project.
One note: please don’t touch any of the resources whose name is “EndTB Customization of xyz”, as these are for a specific set of implementations and are not general purpose.