Thank you so much for the kind words and enthusiasm! I should mention that much of the work on the Portuguese translation was already done—I simply completed it. But it’s always a pleasure to contribute to such an impactful project like OpenMRS.
You’ve made a great point, and I agree that keeping efforts united is important. The nuances between pt and pt-BR are indeed minimal, especially in the context of OpenMRS, so maintaining focus on a single base translation makes sense.
That said, I think it might be helpful to have a repository or mechanism—like a JSON file for translation overlays—where country-specific adjustments could be stored. For example, in Brazil, “Salvar” is the standard term used for “Save,” whereas “Guardar” is more common in Portugal. Similarly, “Curativos” in Brazil are “Pensos” in Portugal. These differences might not be significant for functionality, but they do impact user familiarity and comfort.
To fully address this, I’d need to review the translation in detail to identify more of these discrepancies. This approach might let us preserve a unified translation effort while still allowing for localization where it truly matters.
I’d love to hear your thoughts on this idea, and I’m happy to help however I can!
Thanks again for the encouragement and for all the hard work you do for this community!
I also wondered how these rules would apply to database calls to concepts when the UI required a stored concept to be displayed. I had hoped there would be a hierarchical rule which displays the country-specific term if present, if not, return the non-country-specific locale and finally return the English term (since every concept usually has English). Is there something similar which would allow people to only add country-specific locale information when it differs from the default locale for that language?
As I started reviewing the translation, I noticed a critical point that might cause confusion for Brazilian users. Since the base Portuguese translation seems to follow the European standard, the term “utente” is used for “patients”/“health care users in general”
In Brazil, “utente” is not a familiar term (it might not exist on dictionary I am a physician native from Brazil and never heard); instead, we exclusively use “paciente” to refer to patients. Interestingly, “paciente” is also valid in Portugal, so it seems like a more universally compatible choice.
To ensure better usability and avoid confusion for Brazilian users, I plan to replace “utente” with “paciente” across the translation. Does that sound okay to you?
Thanks for your guidance, and let me know if there’s anything else I should consider!
P.S. Is there some other place to discuss this kind of particularities?
The whole reason we have a forum is for whatever kind of conversations the community needs to have, so here is great. We also have a Slack instance if you prefer.
Given the translation flow for concepts, can something similar be done for messages, since then only the differences from language would need to be documented?
So the message codes already fallback from, e.g., pt-BR to pt when it’s not found. The difference is if the message isn’t found in pt-BR or pt, it falls back to en-GB.
I am excited to share that the Brazilian Portuguese translation is now complete, and some items have already been reviewed. @ibacher@akanter@grace Thank you guys for your support!
Now, I’m wondering how to properly implement this translation. From what I understand, there’s a CI/CD process that handles this operation, but the information available in this thread seems outdated.
I’ve already configured my Docker installation with the following setup:
<config>
<globalProperties>
<globalProperty>
<property>locale.allowed.list</property>
<value>en, en_GB, es, fr, he, km, ar, vi, pt, pt_BR, zh</value>
</globalProperty>
<globalProperty>
<property>default_locale</property>
<value>pt_BR</value>
<description>Specifies the default locale. You can specify both the language code(ISO-639) and the country code(ISO-3166), e.g. 'pt_BR' or just country: e.g. 'pt'</description>
</globalProperty>
</globalProperties>
</config>
However, this configuration does not seem to work. Additionally, the documentation available at O3 Translations Configuration is quite superficial for the use case of newly added translations.
Could someone provide updated guidance on how to properly implement a new language translation like this? Any help would be greatly appreciated!
hello, i got some challanges with transifex, for i had used it in free trial, but trying to go to openMRS transifex i actually hit the page not found , is it that i have to use the charged domain, or there r some issues as per now
Interesting problem! @nethmi I think you’ve dealt with this right? I’d love your help with this situation. The problem is we can’t get the pr_BR to show up in @filipelopes’s distribution (and he has a go-live date in a few weeks). And yet what he’s done above looks exactly like what we had to do to set French as the default locale for the DRC team here.
My initial reaction is: Is there somewhere else where he needs to also specify the default locale?
EDIT: I see that in the few hours it took me to write this, it seems like @filipelopes’ test instance is now correctly showing pt_BR as an option. Will find out what needed to be changed and will make the docs more clear so future folks don’t have to suffer
This has exposed for me that we need some guidance on default_locale in the new How to Translate OpenMRS wiki page, beyond this other talk answer. I’ve started a very rough draft section for this here in the translation guide.
Thanks our dearest madam @grace , Luganda is the key, when it comes to patient interaction in Uganda.As in the population usually want to take question from medical workers in the lunguages that is easier for them , more so when sick, thanks much
This problem would have impacted basically any org that wanted a country-localized version of a language, including en_GB, not only Brazilian Portuguese - so thank you @filipelopes for catching this!
I should mention that much of the work on the Portuguese translation was already done—I simply completed it. But it’s always a pleasure to contribute to such an impactful project like OpenMRS.
