If you re not into packaging and if you asked how you could help Debian, someone probably suggested that you help to translate it.
It s true that translating Debian is essential if we want to make Debian available to everybody on the world. There are many persons who are stuck as soon as they get a message in English, so it s important to aim for 100% coverage in terms of localization.
Some vocabulary: localization vs internationalization
Internationalization (i18n) is the work that makes it possible to translate messages in a given application.
Localization (l10n) is the work of translating messages of said application. So as a translator, you ll be doing localization but some knowledge of internationalization is still useful because it will define how you re supposed to provide the translations. We ll come back to that later.
Join your localization team
Usually the translation work is shared among multiple translators within a localization team. Check out the
Debian International page on www.debian.org to find out instructions for translators for each language.
Many teams have a
debian-l10n-*@lists.debian.org mailing list used for coordination, feel free to ask questions on those lists when you start (but make sure that you have read the relevant documentation before).
Each team has its own workflow, so observe for a while to get used to what s happening before asking your first questions.
What is there to translate?
The translation of most of the software provided by Debian is not handled by Debian. The Debian translation teams only handle the translation of:
Now before contributing to your first translation, I have to come back to internationalization to teach you a few things. In the above list, the projects marked with (*) do use PO files for their translation and the next sections will explain you how to work with those files.
Introduction to Gettext
The free software community has mostly standardized on a single internationalization infrastructure known as
Gettext. With this tool, you re provided a POT file which contains all the translatable strings. It looks like this:
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR Software in the Public Interest, Inc.
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <email>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: dpkg 1.16.1\n"
"Report-Msgid-Bugs-To: debian-dpkg@lists.debian.org\n"
"POT-Creation-Date: 2011-09-23 03:37+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <email>\n"
"Language-Team: LANGUAGE <ll>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"
#: lib/dpkg/ar.c:66
#, c-format
msgid "invalid character '%c' in archive '%.250s' member '%.16s' size"
msgstr ""
#: lib/dpkg/ar.c:81 lib/dpkg/ar.c:97 lib/dpkg/ar.c:108 lib/dpkg/ar.c:112
#: lib/dpkg/ar.c:134 utils/update-alternatives.c:1154
#, c-format
msgid "unable to write file '%s'"
msgstr ""
[ ]
The lines starting with #: are comments that indicate the source files where the (English) string is used. This can be useful if you want check the source to have more information about how the string is used.
The lines starting with #, contain flags that can be important. If the fuzzy flag is set, the translated string is not used because it must be updated (or at least verified) since the original string evolved. The c-format flags indicates that the string must be a C format string, this has some implications in what s allowed in the string (in particular when it embeds conversion specifier for arguments submitted to printf-like functions).
Another thing to note is that the translation of the empty string is used to store some meta-information about the translation itself.
Contributing a translation as a PO file
When you start a new translation, you copy that POT file to create a PO file for your own language (eg. fr.po for the French language). You replace some template values (identified with the upper case words in the POT file) and you replace all the empty strings on msgstr lines with the translation of the string that appears in the previous msgid line.
The result could be something like this:
# translation of fr.po to French
# Messages fran ais pour dpkg (Linux-GNU Debian).
msgid ""
msgstr ""
"Project-Id-Version: fr\n"
"Report-Msgid-Bugs-To: debian-dpkg@lists.debian.org\n"
"POT-Creation-Date: 2011-09-23 03:37+0200\n"
"PO-Revision-Date: 2012-01-16 07:57+0100\n"
"Last-Translator: Christian Perrier <bubulle>\n"
"Language-Team: French <debian-l10n-french>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: Plural-Forms: nplurals=2; plural=n>1;\n"
"X-Generator: Lokalize 1.2\n"
#: lib/dpkg/ar.c:66
#, c-format
msgid "invalid character '%c' in archive '%.250s' member '%.16s' size"
msgstr "caract re invalide %1$c dans la taille du membre %3$.16s de l'archive %2$.250s "
#: lib/dpkg/ar.c:81 lib/dpkg/ar.c:97 lib/dpkg/ar.c:108 lib/dpkg/ar.c:112
#: lib/dpkg/ar.c:134 utils/update-alternatives.c:1154
#, c-format
msgid "unable to write file '%s'"
msgstr "impossible d' crire le fichier %s "
[ ]
If there s already a PO file for your language, there might still work to do: there might be strings that have not yet been translated and there might be fuzzy strings which have to be updated strings which were already translated but where the original string has been modified.
There are software that can assist you to edit PO files:
poedit,
virtaal,
lokalize,
gtranslator. There are also special extensions
for vim (packaged in
vim-scripts) and
for Emacs.
Submit the translation for inclusion
Once you have a complete PO file, you should submit it for inclusion. Sometimes you will have been granted commit rights to the source code repository so that you can include your translation by yourself. In the other cases, you should submit your translation with a bug report tagged l10n and someone else will include your work in the next release.
Depending on the team, the workflow might require a review before the submission. In that case, you usually have to send a call for review on the coordination mailing list.
Go ahead!
Hopefully those explanations will be enough to get you started. There are many other things to learn but it s good to learn while practicing
For example, can you find out why the French translation above changed %c in %1$c ?
Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.
No comment Liked this article? Click here. My blog is Flattr-enabled.
Aptitude package manager is undergoing a revival. Two fellows, Daniel
Hartwig and Manuel A. Fernandez Montecelo, started triaging bugs and
preparing a possible new version.
Daniel Burrows, who maintained it for years (and did a really good job
in this, given the high exposure of aptitude, which happened to be the
recommended package managers during a few years), has currently less
free time for doing the work.
So, this is really great to see people motivated in taking the job
over.
In case you want to help, please joing the "aptitude-devel" mailing
list on lists.alioth.debian.org. There is an Alioth project but Daniel
is currently the only administrator. I might ask for admin privileges
so that I can validate new team members.
Of course, I personnally can't do much in this (C++ programming,
coding, ah ah ah...things that are black magic for me), except my
usual help for i18n/l10n. But, at minimum, I can make noise about this
effort to encourage the volunteers who commit themselves to revive the
project.
And, I can certainly help by sponsoring their work (none of them is DD
as of now) even if I am not skilled enough to review everything. I
don't want to see good work wasted because people insist on nitpicking
each and every commit line before "approving" it (any idea what I'm
talking about, here? :-)).
