lesson-example icon indicating copy to clipboard operation
lesson-example copied to clipboard

Notes about translations workflows

Open dpshelio opened this issue 6 years ago • 1 comments

There's two main ways we need to decide how they are going to work:

  1. English as master - other languages as translations
  2. All the languages go in their own way (e.g., wikipedia style)

In either case, we need a mechanism to feed back to the the other languages about possible improvements.

At the moment I imagine the logical path would be to translate from English as a starting point. Other language communities haven't got the weight English has at the moment (Instructors, maintainers, ...). To do so we should learn from open source communities to manage the translations in the most efficient and sustainable manner.

There's plenty of tools that Open Source projects have been using for decades to organise the workflow (gettext, Omegat). I've recently spent time with people that coordinate translations for Gnome and got a better overview of how we can apply that to the Carpentries material. They all told me that tools like transifex, Zanata were not that good (but I've not got enough experience with them to judge).

In the case of the documentation Gnome uses Mallard as a format, and there's a lot of tools around it to make it easy. Then they have different translation communities organised in teams. Each team organise their translations cycles as they wish. Normally, there's a two weeks period from the changes freezes moment till the release where most of the translations are done. The French normally don't do any translation before that time, then they have two weeks where everyone is translating.

Even though they use Mallard as the ending format they use gettext and PO files a system that has been shown powerful in many communities and for which there's a lot of tools that can use this format and that contain lots of extra functionalities to make it easier (PoEdit, GTranslator, Lokalize). The advantage of using PO files is that you can update the PO file with a new version of the source and it will know what things need translation and which ones don't.

Fortunately, someone wrote a po file generator for markdown and though it didn't work straight away with Carpentries material, I've managed to make it work (darkcircle/po4gitbook#1)!! Yay!! (still, some tests need to be written to make it solid).

With this tool we can generate the po files and generate the material straight away, ready for website generation. Now, what's the best way to keep these files? Should they be version controlled? How should the material be kept? Normally there's a locale directory under the package: e.g., shell-novice/locale/es. This could be a git submodule, and for the po files, we could have all the lessons under a common repository po/shell-novice/_episodes.es.po which the template (pot) could be generated at a particular times - say, once every month - and pull requests of the translations bits are created during the time to modify the [language].po files.

With a bit of travis magic then we could produce a website indicating the stats for each language and for each lesson and section. And all this work can be done without affecting or depending of the maintainers of the source lessons.

How does it look? What experience the people in the community have to find a better workflow?

@javijevi, @agbeltran, @rgaiacs, @ErinBecker, @tracykteal, @naupaka, @ChristinaLK

dpshelio avatar Nov 20 '17 22:11 dpshelio

@ErinBecker Can you add a new section mention the translation process?

rgaiacs avatar Feb 13 '18 17:02 rgaiacs