Skip to content

Drumming Up

During LinuxTag 2010 in Berlin I discussed internationalization issues with a bunch of people from major Linux distributions. I hereby express my gratitude to all of you and will summarize my impressions. Any errors are very likely to be me mixing up the facts and I would be pleased to learn better from you!

Gentoo‘s tools remain mostly untranslated. There is no coordinated i18n effort and, if at all, they use plain PO files with a strong dependency on shared translation memory.

For software, FreeBSD follows the same strategy. They have a German manual in DocBook format which can be translated and pushed to version control. To maintain a uniform language style translators need to work on whole chapters. Issues are resolved through their mailing list which will supply SGML markup to plain text translations or pick up half-finished ones. Updates to the reference documentation are tracked through revision numbers.

The Sidux manual follows a similiar workflow: there is one person writing the reference documentation in English and one maintainer in charge per translation. Changes propagate by word of mouth.

Debian has the excellent Debian Description Translation Project (DDTP) which handles translations via e-mail and has a built-in notion of review. Their home-brewn web interface Debian Distributed Translation Server Satellite (DDTSS) acts as a gateway to their mail server.

Localization is a core value in the KDE culture. They have a lot of documentation on internationalization issues and try to remove friction where possible, eg. by encouraging semantic markup and context in translatable strings.
Approaching releases there are time spans where translatable strings ought not be changed by developers. This guarantees there are translations available on release date.

OpenSUSE has its translations for YaST and other system components stored in a central SVN repository. PO files are modified locally and aided by a shared memory. msgfmt statistics are adequately visualized.

I also had the chance to talk to Henning Eggers of Canonical at the Ubuntu BBQ who is part of the Launchpad Translations team. I learned that they are actually a pretty shallow layer above gettext message catalogs and settled for providing utilities such as shared translation memory around the actual process. Fuzzy translations are discarded because wrong translations are absolutely fatal to their use case. Henning mentioned they would be interested in change tracking (for instance by means of edit distance between two msgids) but do not have any such mechanisms in place currently.

I heard users absolutely want translation services to Just Work™ when they invest time in localization. Errors bubbling up from maintainers’ faults (such as  duplicate msgids) which inhibit their productivity usually kill motivation. Better diffs and change tracking seem to be a key feature people are looking for.

Post a Comment

Your email is never published nor shared. Required fields are marked *