You can approach debconf translation work in two ways: you can be active and seek out packages to translate and update, or you can be reactive and translate and update packages when someone requests it to be done. Usually, nobody takes a purely active or reactive stance; for example, lately I used to react to calls for translation updates, but when I had some spare time I would go translate a couple of new packages.

When you work actively, the web page whose URL you need to know is http://www.debian.org/intl/l10n/po-debconf/. There you have links to all languages for which there are translations. Click on yours, and you’ll see a page listing the state of every source package’s debconf template translations for your language. First, you see the partially-translated packages, then the fully translated packages, and finally a list of packages which are not translated to your language. For each package in the first two sections you can download the .POT and .PO files; the names of the packages in the last section just link to a big webpage from which you can download every package’s .POT file.

In the top part of the page you have links to other useful pages. An interesting one is the ranking page, which lists all the languages in order of completeness.

For working reactively, you need to subscribe to the debian-i18n mailing list, because when there is a call for updates or for translations it is always sent to that mailing list. Also, if there already is a translation for your language, another email will be sent to the translation group’s mailing list, as well as to the file’s latest translator.

Calls for translations include information on the deadline and the package maintainer’s preferred methods for submitting the translation. There may also be some notes from the package maintainer. Finally, the .POT file is attached to the call for translations sent to debian-i18n, while the old .PO file is attached to the call for translations sent to the group and the latest translator.

Calls for translations can be sent by the package maintainer when the debconf templates have been modified and the translations need to be updated, but they can also be sent by other people for many other reasons. For example, for the last months there’s been a campaign to upload packages for which there were newer translations that hadn’t been uploaded yet, so NMUs for these packages (non-maintainer uploads) were announced, including a call for translations. Also, there was a campaign to review all packages’ debconf templates, make them more consistent, improve their grammar, etc., and a call for translations was issued for every package after the review.

Running the Galician debconf template translation as an one-man show has an obvious problem: translations don’t get reviewed. Being only one, I would only catch typos, and the odd thinko, which is not very useful. The real use of reviews is to see if the grammar is sound, see if the translation sounds natural or forced, etc., and it has to be someone else who does it. If I review my own translations, of course they’ll be perfect.

When someone else picks those translations up after I stop doing them, it would be useful to make a full review. Fortunately, I’ve been keeping a compendium of (almost) all debconf template translations, so doing the review is as simple as downloading that single file and reading it.

I’d recommend that one single person read the full document and makes notes of grammatical/orthographic mistakes, common patterns, vocabulary choices, etc., and then those notes should be used to go through the compendium again and fix and update everything. The result would be useful for two things:

First, it is a very big collection of examples you can point people to when they don’t know what style to use to translate. So, when someone asks in the mailing list about the best way to translate “Couldn’t create temporary file”, you can search for similar sentences, see how they were translated and suggest the same solution.

Second, you can use that compendium to apply the results of the review to all translated packages very quickly. The idea is to regenerate the .PO file from the compendium. You can do it actively (see what packages have had their debconf templates translated into Galician, download .POT files, apply compendium, upload .PO files) or reactively (when you have to update a .PO file, download the .POT instead and apply the compendium, then update the resulting .PO file).

As some of you know, I’ll stop working on Galician translations (of everything) after Lenny is released (or after the end of October, if Lenny is not released before). Before that, I’m going to start documenting several aspects of my work on it in several blog posts. I’m not going to follow any particular order; when everything’s written, I’ll collate the documents and make them available together in a single coherent document.

Although it is written for the future Galician team, this work (even the final document) will be written in English. If it is a problem for anyone, I don’t want them as translators. And, also, this will make this document potentially useful for other teams.

The Debian installer system (d-i, for short) is made up of several components. Some of these components were written especially for the Debian installer; others, however, are standalone applications which are used during the installation of Debian. The translations of many of these components are managed separately; however, an effort is being made to keep track of them, providing a single dashboard where a translator can see the status of the d-i translations, get files to translate, instructions for submitting the translations, etc. This dashboard resides at http://d-i.alioth.debian.org/l10n-stats/.

There is a translation guide for d-i, explaining what components are in each level, how to retrieve the files to translate or update, and how to submit the translated files. I’m giving here a short summary in this post.

For translation purposes, d-i is divided in five levels. Level 1 contains the strings everyone sees when installing Debian — the following levels contain components whose translation is less user-visible. Therefore, when translating d-i you should prioritize level 1 translations, then level 2 translations and so on. However, this doesn’t mean that they are any less important; you should try to always keep them up to date!

You can see the status of every language in each level by going to the l10n-stats page. If you click on a language you can see a text file with a more detailed report on the translations for that level and language. You can also opt in to receive emails every morning when the status in a level for your language changes — you’ll have to ask Christian Perrier to subscribe you to the websec-txt notifications for your language.

Level 1 translations are maintained on Alioth, so you should get an Alioth account and request to be added to the d-i project as translator. Then, you’ll be able to download and upload the translations using Subversion. There are lots of programs and packages that comprise level 1; however, to make translation easier and more efficient, the translations are consolidated in only 5 files (called sublevels). In this way, if the same string appears several times in several programs, you only need to translate it once. It’s 5 files instead of a single one so that it’s easier to distribute work, assign priorities, etc.

The other levels consist of translations of individual programs, which are maintained in many different ways. The particular methods you have to use for each package are detailed in the translation guide. For most of them, it involves downloading the .POT or .PO file from a read-only version control repository, and uploading the translation using the Debian BTS.