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.
