Interview with Lukasz Jernas of the OpenStack translation project

How OpenStack gets translated

Image by : 

opensource.com

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.

Q&A

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!

OpenStack Summit
Speaker Interview

This article is part of the Speaker Interview Series for OpenStack Summit Vancouver, a five-day conference for developers, users, and administrators of OpenStack Cloud Software.

1 Comments

r3bl

Translating is (in my opinion) the easiest way to start contributing to an open source project. That's usually my first step in the process. While I'm translating the project, I'm also getting to know the team and inspecting the code. After I finish translating something (or find someone to fill my spot), I usually have a decent knowledge about the inner workings of the project. Because of this it's much easier for me to start contributing to other areas of the project as well.

I'm lucky I live in an area where I speak three languages on a native level. Also, my English skills are getting better and better (I understand everything, but I still have some difficulties with the grammar while I'm writing and speaking) and I know a bit of Dutch as well. Because of that, it's easy for me to find something to translate in ANY open source project I can think of.

But you're right, translating can also be very stressful. As an example, 10 days ago I downloaded a file where I needed to translate more than 200 strings. So I started working on it right away. It took me three or four hours to translate everything (most of the strings were a couple of sentences long), and when I finished, I found out that somebody had already submitted the translation of that file. So, I basically spent a few hours for nothing.

Also, there are some words (like the word "edit") that are pretty difficult to translate in my language, because there's like four or five synonyms for that word that you can use. Because of that, you have to be extremely careful to choose and use one synonym for that word throughout the project. If you're not translating the project alone, you have to speak with the other members of your team so you can agree which translation will you use for those kind of words. As a consequence, users see one word used as a translation for something in one project and another synonym of the same word used as a translation in another project they're using. This confuses the users A LOT.

Vote up!
1
Vote down!
0