In order for an open source project to have a truly global reach, it must reach its users in their native tongue. OpenStack is no different. In order to bring open source cloud computing to countries around the world, a dedicated team of individuals helps translate both the project itself and its documentation into the native language of numerous peoples.
One of the translators working on that effort is Łukasz Jernaś. Jernaś is a software engineer for the Allegro Group doing internal tools development in Python, but he is a systems administrator by heart. He started working on OpenStack around the Grizzly release, when the company he works for deployed its first private cloud. Striving to keep his environment in his native language, translating Horizon (the web-based interface to OpenStack) seemed a natural thing to do.
We caught up with Jernaś to learn a little bit more about the translation process, and about the talk he'll be giving at the OpenStack Summit in Vancouver in which he shares a little more about OpenStack translation.
Without giving too much away, what is your talk going to focus on? What are some of the challenges facing OpenStack translation, and how are they being addressed?
Developers, developers, developers. Just kidding (partially). As usual, the most challenging thing is time and translations being a constantly moving target during the release cycle, which gives everyone a small amount of time to finish our jobs. A second issue is educating developers on the proper usage of the i18n and l10n toolset they have at their disposal, so the messages and actions the users sees don't end up feeling awkward. Other than that, you'll hear about some things to look out as a translator, what can we do to improve the process and friendliness to our translators (at least from my experience), and how to get started.
You've been involved in open source for a while. How would you say OpenStack compares to other open source projects in terms of translation?
Comparing Havana (the first release I fully translated Horizon) to Kilo, OpenStack has matured a lot. Translations still aren't seen as that important in some parts of the user community, so we don't get as many contributions as more user-facing projects (e.g. desktop environments or applications), making some of the teams one man teams. Although the current hip words are "agile" and "lean," some more processes are still needed, in my opinion, both to shield translators from unnecessary last-minute string changes, and to at the same time giving the developers feedback that they did something which creates additional work for multiple people. The other project I was working on before did exactly that, and I feel it's a worthy thing. Last minute changes happened less and less with every project, as the developers got accustomed to "freezes" being real freezes. We enforce that already for code, strings would be a welcome addition!
What are some of the tools used for managing translations for OpenStack, and how do they facilitate the process?
Right now we mostly do our work in and around Transifex, although this may change in the near future in a way that would allow us to give more kudos to translators. Other than that, Akihiro Motoki, Andreas Jaeger and Ying Chun Guo (our coordinator) maintain a set of scripts integrating the translation platform into the OpenStack infrastructure (gerrit, zuul, etc). It's not that complicated: mostly some post commit actions which update the POT files (translation templates with original English strings) and automatically fetching updatetranslations from Transifex to integrate in the code. Also, for the last few releases Akihiro Motoki has provided us with a devstack instance, where we could test our translations in a "live" environment. So if you allow, I'd like to shout out a big "thank you!" for these people.
How does OpenStack's release cycle play into the translation process? Is it manageable to get translations done on a six-month release cycle?
Most of the work gets done after the string freeze period, which happens around a month before the release, with a lot of it being completed after getting the first release candidate out of the window. Documentation is translated during the entire cycle, as many parts are common between releases and can be deployed independently to the releases. So we don't have to focus that much about deadlines, as it's available online all the time and not prepackaged and pushed out to users and distributions. Of course, having a month to do the translations can be cumbersome, depending on the team doing the translation (some do that part time, some people in their spare time), and how many developers push out new strings during the string freeze. It is not uncommon to having to have new strings land a few days before a new release, and all the teams have to update the work which was supposedly finish. There's nothing worse than seeing the 100% translated mark being reduced after a late night sprint, so please developers—help keep your translators sane!
What is the relationship between translating strings within the actual software and translating other resources like documentation? Does the same team work on both?
I can't really tell about the other teams, but from my experience it's usually the same people doing both translations. Software is usually a lot easier to translate, but that highly depends on the language it's being translated to. For example, most documentation is hard to translate into Polish, because many English sentences are more or less gender neutral, which is not the case in Polish. So you either have to choose your reader (not recommended) or rewrite the sentence in a gender neutral fashion.
If a reader were interested in getting started with the translation effort, how would you recommend he or she get started?
Join the openstack-i18n mailing list, read the wiki, and contact your local language coordinator, or become one! We also hold a bi-weekly meeting on #openstack-meeting in Freenode IRC at 08:00 UTC, so feel free to drop by and grab us (the next meeting is usually announced on the mailing list). We don't bite and contributing your first translation is easy, you only need to be able to open a website!