Step 1/4 l10n framework: Import of translatable strings
Current Debian l10n statistics pages[1] are provided by extracting
all translatable materials found in Debian source packages. This
does work quite well in practice, but there are several problems:
a. Translators may work on files which have upstream translators.
This is true for GNOME, KDE and many more projects.
b. There is no safe way to extract translatable material from
source packages. Some maintainers use yada[2], patch PO files
on-the-fly, etc[3].
c. On the other hand, some files (for instance unit test files)
are grabbed whereas they should not be translated.
Translated materials are usually embedded in Debian packages[4].
For this reason, developers are responsible for these translations
and want to manage them[5]. One solution is to adopt a system
similar to the Free Translation Project[6]. Developers send their
files to a centralized system, wait for few days/weeks, get
translations from there and upload.
Another solution is to let them commit translatable material into
a centralized repository.
Both approaches are an opt-in system, developers will give files
to translate only if they want them to be translated by Debian
translators. These solutions solve the points mentioned above,
but require some amount of work from maintainers. We could
provide a tool to ease this work; maintainers would write a
configuration file per package, and a tupload command would
automatically upload translatable material into the system.
A simpler approach is to add a user field[7] into debian/control,
say
XS-L10n: debian
There would be a predefined list of values (debian, gnome, kde,
ftp, etc.) and links to upstream translation teams could be
provided by the l10n web server.
This is also an opt-in system, so we can hope that maintainers
are interested in improving the l10n of their packages and will
follow a filename policy to avoid points (b) and (c) above.
The last approach is very easy to implement, but looks much
less flexible than the previous ones. If we do not need extra
complexity, I would prefer this one.
Denis
[1] http://www.debian.org/intl/l10n/
[2] Yada sucks. Really. I need to do something about #321139
[3] po-debconf templates are easy to manage because Debian developers
are upstream for these files, so they do not have to be patched.
Their path is also hardcoded into debian/po, but some maintainers
still move them around, see #353146.
[4] The only exception I can think of is package description, it is
unclear whether they should be managed within binary packages or
by archive maintainers through translated Packages files or
via another file.
[5] See this thread
http://lists.debian.org/debian-devel/2003/02/msg01924.html
[6] http://www.iro.umontreal.ca/translation/HTML/
[7] http://www.debian.org/doc/debian-policy/ch-controlfields#s5.7
Reply to: