Translations Server


(Saptarshi Purkayastha) #1

While I’ve liked the idea of getting translation contributions, I find the Transifex UI to be very complicated. Particularly for a single view and stats about updates. I like the POEditor UX, and also that its integration with github, gitlab and others is quite nice. Apache hosts its own Pootle server, which is shared by multiple projects, but I think we shouldn’t host our own. If others agree, I think we should ask for a POEditor OSS project and use that for all LibreHealth projects?

(Michael Downey) #2

I would be wary of hosting a Pootle server this early on. I agree Transifex isn’t too user friendly, and I also dislike that it’s not free software. So, personally, I feel the same about POEditor. I feel like it shouldn’t be too hard to get a hosted Pootle instance somewhere, but we should look into what’s available generally in terms of translation services and make the best choice after due diligence.

(Tony McCormick) #3

This is an interesting topic for the EHR as well, current translation work is done in a google doc that only open-emr project controls. It’s pretty cool but not going to be accessible to us. The EHR has a string editor, but not a coordinated / group way to manage all of that.

(Art Eaton) #4

String to string matching is foolish and short sighted anyway. Inserting an array index along with permutation arguments is far cleaner than putting in a string, hoping it matches something, looking for a match based on case. The potential for contextual misinterpretation based on use in several places is very bad. I would like to simply replace all strings and list content in the EHR with an array or arrays per module/distinct component.

(Saptarshi Purkayastha) #5

The big claim for externalization of strings as a best practice is that it allows for translations of the application in runtime. But is there value, really, in someone using one page in say Hindi and then switching locale and saying, “oh so thats what they call that in English”? and basically using the EHR as a tool to learn a language… surely not, I say!!

I guess the reason to externalize is to allow contributors who come from different contextual backgrounds to make the text suitable to the way its used, without needing to know where in code to find it. They do need to know where in the UI it is going to be shown… So a translation service has to be able to show a demo out

(Saptarshi Purkayastha) #6

I want to minimize the infra that we manage. Do you know of a hosted Pootle service that we can use, ideally for free? that also has configuration to commit to git.

(Robby O'Connor) #7

The less infra we manage, the less infra we have to monitor.

(Art Eaton) #8

Inclusive professional language by country

  • English- 101 countries
  • Arabic- 60 countries(multiple dialects but fairly compact)
  • French- 51 countries
  • Chinese(but combined of 5 dialects and text)- 33 countries
  • Spanish- 31 countries
  • Persian- 29 countries
  • German- 18 countries
  • Russian- 16 countries
  • Malaysian- 13 countries
  • Portuguese- 12 countries

Most studied professional languages:

  • English- 1.5 billion learners
  • French- 82 million
  • Chinese- 30 million
  • German- 14.5 million
  • Spanish- 14.5 million
  • Italian- 8 million
  • Japanese- 3 million

My personal belief for disbursal for LibreEHR:

  • English
  • Hindi
  • Spanish
  • Arabic
  • Portuguese
  • French
  • Vietnamese
  • Japanese
  • Chinese
  • Russian
  • Tamil
  • Italian

This belief is based on what I see for single language speakers (patients) within a country that also or only speaks English.

In the United States, Spanish, Hindi, Arabic and Vietnamese searches for medical terms top the list. In some regions like Miami, there are surprisingly few searches for Spanish compared to French (Haitian).

On the developer side, Most African programmers seem to speak at least three (spoken) languages, with English among them.

-In the experience of the famous Smokey Robinson, when visiting Kenya in the 1970’s, he was asked:

“So, what language do you speak?” “Uhhh, English!” “Pbbbt! Of course! Everyone speaks English! I mean your native language.” “Uhhh, Jive?”

French is also a vital language in Africa, along with other “conqueror” languages of distasteful origin, but like Latin and the Roman roads, they are now in use and serve as a bridge.

Indian Sub-continent has a similar multi-lingual and colonial past, and a high linguistic education rate, and a lot of developers. That said, it is a damn shame when the developers that wrote the application look at it in their own language, it looks like shit. They developed it, their neighbors should be able to feel they own it.

Spanish. We don’t have enough Spanish speaking developers. Yes, we have some, but it is pure amazing that our application(s) isn’t experiencing a whole ton of interest from Latin America. Same for Portuguese.

-We need to do a better job of outreach. Even in the US, having the ability to translate a Review of Systems form and get meaningful input in another language is very valuable. It is about the patients more than the doctors.

This means looking deep into the effort spent on the translations in our application. We need native speakers and native speaking clinicians to help as well. We can’t depend on translation programs.

(Saptarshi Purkayastha) #9

I agree that we need better translation in all our software. Hosting a pootle server isn’t very resource consuming and I’ve used it in many other projects. Though, I suggest that we use a SaaS that will allow translation contributions such as We could get a open-source free setup if we qualify.