About the Translation Project
The Translation Project (the TP, for short) is meant as a service to both
package maintainers and translators. The advantage for maintainers is that
they need to announce a new POT file to just one address and can fetch the
translated PO files from just one place, instead of having to deal with
several translators separately. For translators the advantages are
similar: they receive the POT file announcements and pre-merged PO files
from a single place and send in their PO files via a single mechanism,
instead of having to deal in different ways with several maintainers
At the TP, translators are grouped into language teams (rather than package
teams) because, in general, translation issues are more specific to a human
language than to a particular package. It is good for translators of the
same language to get together, check each other's work, and discuss any
problematic translation issues. This also increases the chances that all
packages at the TP get translated in a similar manner, using the same
conventions and a consistent vocabulary. Lone translators tend to find
their own ways and words, making your package stand out as strange.
Using the Translation Project
Whenever you make a new release of your package, you should announce it to
the TP coordinators at <email@example.com> by sending them
the URL of the release tarball -- this tarball should contain an up to date
POT file. (If your package isn't internationalized yet, then see below.)
Preferrably you make a prerelease a week or so earlier and announce this to
the TP, so the translators get a chance to update their PO files before the
actual release of your package, so the release can go out fully translated
into several languages. However, if you don't want to bother making a
complete prerelease tarball, you can also just send your latest POT file to
the coordinators and mention the version number of your next release.
Whenever a translator uploads an updated PO file for the latest version of
your package, you receive an email notification. You can then immediately
import this PO file into your source code repository, or you could wait
until just before you make the actual release and use the following command
to import all PO files at once (replace DOMAIN with the name of your
package in all lowercase):
rsync -Lrtvz translationproject.org::tp/latest/DOMAIN/ po
When you make use of the Translation Project, you must not accept PO
files from translators directly but instead point anyone who offers you a
PO file to the TP. Channeling all translations through the TP increases
the chances that they are of good quality (getting checked by fellow
translators) and that they are kept up to date when the original author
goes on to do other things. Pointing translators to the TP also means that
the translation teams get a chance to acquire new members.
Sometimes a translator does not wish to make use of the Translation Project
but instead wants to deal directly only with you. In such a case, when you
accept a PO file directly and the translator promises to keep it up to date
during future releases, then please notify the TP coordinators. They will
then mark the affected language as 'external' for your package, so other
team members know that the translation is being handled elsewhere and don't
do the same work again. If however the translator cannot promise to keep
the translation up to date, then please forward the PO file to the relevant
team leader -- only he or she can decide whether the translation is any good
and follows the team's conventions.
The copyright on PO files
The Translation Project does not require from translators that the
copyright on all PO files be disclaimed. For most GNU packages, however,
the Free Software Foundation (FSF) requires disclaimers. Also for non-GNU
packages it is a good idea to ask for disclaimers, as this better protects
the made translations against people who might change their mind about
freedom; such things can happen. If you decide that disclaimers are
required, the Translation Project checks that translations are properly
disclaimed before being accepted. For a copy of the actual disclaimer text
see translationproject.org/disclaim.txt .
Internationalizing a software package
A full explanation of internationalizing a program is given in
www.gnu.org/software/gettext/manual/html_node/Sources.html , but in
short it comes down to the following steps: 1) importing the gettext
functions into all modules that require translations, 2) activating the
localization at the start of your program by binding to a textdomain, 3)
using a macro to mark all translatable strings that are presented to users
(not debugging messages), 4) adding some autoconf and automake magic so the
translatable strings get extracted into a POT file when 'make dist' is run.
The POT file
In your distribution, the POT file is probably located in the po
subdirectory and named simply PACKAGE.pot, where PACKAGE is the name of
your package. At the Translation Project many POT files are stored, so
there your POT file is named DOMAIN-VERSION.pot -- where DOMAIN is the
textual domain for your package, often the same as PACKAGE but in all
lowercase, and VERSION is the version number of the package it belongs to.
This version number should not consist of more than four elements.
If you generate the POT file using a recent version of gettext (later
than 0.11), the POT file header will be correct as it stands. Only the
POT-Creation-Date will automatically have been filled in for you, while
several other fields contain words in all uppercase. Do not change these
in any way, as only translators are meant to properly replace them.
If you use intltool to generate the POT file, the latter does not get
included in the distribution tarball by default. Adding the following
three lines to your toplevel Makefile.am will get it distributed:
$(MAKE) -C "$(srcdir)/po" "$(GETTEXT_PACKAGE).pot"
cp "$(srcdir)/po/$(GETTEXT_PACKAGE).pot" "$(distdir)/po/"
To announce a new POT file, merely send the URL of a packaged distribution
of your program to <firstname.lastname@example.org>. Best is to use
the string "DOMAIN-VERSION.pot" somewhere in the subject line of your mail.
The Translation Project will process a POT file only once, so another
submission must use a newer VERSION. The distribution tarball pointed to
by the URL does not have to be official, it does not even have to compile:
its goal is merely to provide finer context for strings to be translated,
in case translators need such references.
The very first time you submit a POT file, the Translation Project also
needs to know which email address to use for notifications, and if you want
translated PO files sent in full to you or a mere URL pointing to them.
You may submit new POT files as often as you want. You might wish to avoid
exhausting translation teams, but we have never yet received a complaint.
So don't hesitate submitting it if just a few weeks after the previous one
you have a new release.
Let the teams do their work
Please do everything in your power to respect the autonomy of translation
teams. Do not try to push or pull on teams or translators, nor otherwise
interfere with them. If a team does not work fast or good enough for your
taste, this is a matter between the team and the users of that language.
The teams are responsible for deciding on which files to work first and
also for the linguistic quality of their translations; as a package
maintainer do not try to guide or influence this.
If ever you receive linguistic gripes from users, direct these users and
their gripes to the language teams. The relevant address can be found on
translationproject.org/team/index.html . Do not edit or change the
PO files in your repository directly, as this would undermine the authority
of the language teams and defeat their purpose. Also do not accept any PO
file from a translator directly, but please point the person who offers it
at translationproject.org/html/translators.html .
If any question remains, don't hesitate to ask a TP coordinator,