Package maintainers and the TP
About the Translation Project
Using the Translation Project
The copyright on PO files
Internationalizing a software package
The POT file
Announcing
Let the teams do their work
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 separately.
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.
Whenever you make a new release of your package, you should announce it to the TP coordinators at <[email protected]> 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.) Preferably 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.
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 two commands to fetch all the PO files at once (replace DOMAIN with the name of your package in all lowercase):
rm po/*.po
wget --recursive --level=1 --no-directories \
--accept=po --directory-prefix=po --no-verbose \
https://translationproject.org/latest/DOMAIN/
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 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 they are accepted. For a copy of the actual disclaimer text see translationproject.org/disclaim.txt .
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.
In your distribution, the POT file should be located in a po subdirectory and named simply PACKAGE.pot, where PACKAGE is the name of your package (in lowercase). 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 (in most cases the same as PACKAGE, also in lowercase), and VERSION is the version number of the package it belongs to. This version number should not consist of more than four elements.
In the generated POT file, the POT-Creation-Date will automatically have been filled in for you. Several other fields will 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:
dist-hook:
$(MAKE) -C "$(srcdir)/po" "$(GETTEXT_PACKAGE).pot"
cp "$(srcdir)/po/$(GETTEXT_PACKAGE).pot" "$(distdir)/po/"
Ensure that your tarball unpacks into a directory that has the same name as the basename of the tarball: PACKAGE-VERSION, in all lowercase.
To announce a new POT file, merely send the URL of a packaged distribution of your program to <[email protected]>. Best is to use the string "DOMAIN-VERSION.pot" somewhere in the subject line of your mail. The TP coordinators will process a POT file just once, so another submission must use a newer VERSION.
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.
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, <[email protected]>.