-
Release engineering and translations
-
Here’s the tricky part about translations and release engineering.
Software is written. Software is packaged, released. And users use it. Some of these users do not have English as a native language. This group is around 90% of Earth’s population and around 70% of the Internet’s users. Obviously, they’d prefer the UI and Docs in their native language. In fact, more than 60% of Fedora’s users do not use an English desktop. They use a translated one. Spanish, German, Punjabi. Installer, GUIs, documentation, booting, error messages.
We care about those Fedora users. Heck, they could be something like 4 millions of them. And that’s why L10n projects exist. That’s why there are more than 400 active Fedora translators contibuting in a lot of languages. Anaconda, the Fedora installer, is shipped to more than 60 languages (counting only those with a considerable completion percentage). The Fedora website speaks more than 20 languages. Considering that this is almost exclusively volunteer community work, I’d say our groups of translators are doing an amazing job.
Being one myself, before starting hacking on our Localization Infrastructure, I can’t say it’s an easy job. Usually one has to track a big number of projects, and request access for all of them (last time I counted I had 15+ hosts to monitor). Then, a translator tries to use automated ways to find when, where and how many strings have been changed. Get the files, translate them, send them back. Repeat every few days.
So, what are these guys asking from us? (Besides better tools), they ask for two basic things, basically:
- Please let me know of a date (let’s call it string freeze) when you will complete your work in modifying the strings of your application. Then I can make sure to get your app 100% localized, since it’s impossible for me to work if you change them all the time.
- Please let me know of a date (let’s call it translation deadline) until which I can send contributions to be included in the release. There isn’t much meaning for me to spend my nights after $dayjob if my work isn’t going to be included in the next release.
Adding these two dates (’string freeze’), and ‘translation deadline’) on any project’s schedule is the minimal thing the translators ask. Adding them on the Fedora Schedule was one of the first big changes I sailed to do in the quest to improve Fedora’s (nonexistent until then) L10n workflow.
A distribution is a highly complex project in terms of synchronization and homogeneity — more complex than a lot of big projects out there. We’re still working on making everything actually take place, and get all the people involved follow the guidelines and policies. Even so, I think we’ve come a long way since the old days.
Continuing to improve our processes, the Fedora Localization Steering Committee recently led a communication effort to change Fedora 10’s schedule. We want to make sure translations done by the deadline will end up in the release, so we moved the translation deadline one week earlier. This way, developers will have a period of one week to check their repository for any newly landed translations since the last build, grab them and issue a new build. The new build should, of course, happen before the development freeze.
But then again, mainly due to Fedora’s complexity as a project, it’s a challenge to make sure that those new builds actually happen. To help us in that task, we’ll need a script that works somewhat like this:
- Input: A list of packages, the translation deadline. Output: A list of packages which were not rebuilt to included translations submitted before the deadline. Next to each package we need the maintainer’s email and a randomly generated list of swear words.
- Query koji (the Fedora build system) for the set of packages. Get the latest build of each of them and check if its date is before the deadline.
- For each package that hasn’t issued a build, find out if translations have actually been submitted since the last build (if they haven’t, no need to build). To do so, query Transifex to find out the last date a PO file has changed.
- If a translation has been sent, use
python-bugzilla
(and maybe Fedora’s Package Database to automatically open a bug report against the product. Mark the bug report as a blocker (or target) for the next release of Fedora.
If this sounds like a nice challenge for you, do drop me an email.
Next TODOs for me and FLSCo:
- -7 days from Translation Deadline: Check if any developer has broken the freeze without following the policy.
- -4 days from Translation Deadline: Send a reminder to fedora-trans-announce to remind people to wrap up.
- +1 day after Translation Deadline: Send an email to -devel-announce requesting all packages Fedora is upstream for to issue a new build. Maybe write a script to open bug reports for all.
- 2 days before the Development Freeze: Check if packages have been rebuilt.
And I think that’s it for today’s RelEng+Translations_Howto and personal reminders for the next weeks.
You can use the following: “package name”@fedoraproject.org
That’s an alias to the package owner’s email. That makes one less information to grab somewhere ;)
bochecha: Cool tip, thanks!