In a recent thread on Talk @dl1 is asking about translating to French. I realize that we haven’t discussed translating the Reference Application on the OpenMRS Wiki, or here on Talk. The last public mention I see of this is on the old google groups archive of the implementers forum.
So, I have created a quick wiki page about Translating the Reference Application. Perhaps the next person who actually goes through those steps can improve the wiki page; I left lots of room for improvement.
It would be great if anyone wants to volunteer to do the wrangling around translations, which could involve managing our Transifex account, approving new contributors, occasionally notifying module owners if a lot of translations have happened, and perhaps introducing a process for reviewing translations.
Also, I realize that we probably forgot to add “Ensure that all translations are pulled in from Transifex” as part of our Reference Application release process. @tharunya, did you know anything about this? If not, can you please ensure that this gets added to the release process documentation? I can explain what needs to be done if it isn’t clear from the wiki pages. (@maurya, FYI to you also.)
If you’re curious, here is our current translation status (but I didn’t check whether these have been pulled into the code yet):
+1 to making sure we “Ensure that all translations are pulled in from Transifex”. I think we are getting a lot of good support from translators, we need to make sure we actually pull them into the code base! I try to make sure I keep an eye on the modules I maintain, but we should have something more formal.
I actually have a question about the best way to approach this…
Do we want to automatically be pulling in all translations from Transifex (e.g. daily)?
Pro: translations get in (and visible on our QA environments) fast
Con: nobody necessarily reviews these translations before the modules are released
Or do we this to be a step in the module release process, where it will automatically fail if you try to release a module to which you haven’t pulled in all the translations?
Pro: the module author is forced to affirmatively pull in the translations.
Con: slower to get these to our QA environments
Looking at the Transifex API, it looks like you have the option to choose between getting all translated strings or only reviewed strings. So, a configurable script could support any of these approaches:
Use all translations for testing, use only reviewed translations for releases
Use all translations, reviewed or not, for testing and releases
Only use reviewed translations from Transifex
Projects could decide on how to configure the Transifex download script based on whether or not they can review translations.
This is a good point, and it makes me realize I phrased my question wrong. Whatever we choose to do won’t be too technically hard.
The big picture question is, what should be our translation policy for the large number of Reference Application modules that are community-owned?
Do we want a workflow where reviewers for each language must review translations? (What happens for uncommon languages, e.g. when there’s basically just one person doing all the translating? How does someone achieve the trust level to be a reviewer?)
The “least work” approach work would be to (a) let people be language reviewers if they want, and they’ve reached a certain trust level, but (b) automatically apply translations as they are done anyway, without review, and (c) make a concerted effort to review translations around the time of our twice-a-year Reference Application releases, as part of the release manager’s tasks.
The “more correct” approach would be to (a) have reviewers for each language, (b) automatically apply only reviewed translations, (c) make a concerted effort to ensure all translations are reviewed around release time (or more often), and (d) find an i18n manager to coordinate this.
Do we have anyone interested in being the OpenMRS i18n Manager? Until someone steps up to do this, I’m afraid we’ll have to go with the “less work” approach.
This is a really nice leadership position for someone to take on. We have a lot of people always coming to us asking if there’s something easy they could do to help with translation & internationalization. So whoever wanted to step up to this role would have plenty of people to help out getting tasks done! (As it stands now, without more organized leadership it’s hard for those volunteers to do much on their own.)
Hmm, good point Michael. My original suggestion was that reviewing was going to be too high an overhead—we’ve had translations going on for months that haven’t even be pulled into the codebase, so adding another step seemed like it wouldn’t help. But this other step isn’t a technical one (where we always seem to be short in resources), and there may be non-technical person that would love to take this one–and drive us to make sure we actually pull the reviewed translations into the codebase regularly.
@jthomas, can you please schedule us a design call for this in February? Required attendees are @darius, @mogoodrich, @burke, and @jdegraft (as the refapp 2.4 release manager). @michael is optional but highly desired.
Looking at the present translation state in transifex, even the most translated languages dont have reviewed translations. I would recommend with the least work approach even with the i18n Manager until he can promote a few reviewers and upgrade to the correct approach.
Until someone steps up to do this, I’m afraid we’ll have to go with the “less work” approach.