13.2 Prerequisite Works

There are some works which are required for using GNU gettext in one of your package. These works have some kind of generality that escape the point by point descriptions used in the remainder of this chapter. So, we describe them here.

• Before attempting to use gettextize you should install some other packages first. Ensure that recent versions of GNU m4, GNU Autoconf and GNU gettext are already installed at your site, and if not, proceed to do this first. If you get to install these things, beware that GNU m4 must be fully installed before GNU Autoconf is even configured.

  To further ease the task of a package maintainer the automake package was designed and implemented. GNU gettext now uses this tool and the ‘Makefile’s in the ‘intl/’ and ‘po/’ therefore know about all the goals necessary for using automake and ‘libintl’ in one project.

  Those four packages are only needed by you, as a maintainer; the installers of your own package and end users do not really need any of GNU m4, GNU Autoconf, GNU gettext, or GNU automake for successfully installing and running your package, with messages properly translated. But this is not completely true if you provide internationalized shell scripts within your own package: GNU gettext shall then be installed at the user site if the end users want to see the translation of shell script messages.

• Your package should use Autoconf and have a ‘configure.ac’ or ‘configure.in’ file. If it does not, you have to learn how. The Autoconf documentation is quite well written, it is a good idea that you print it and get familiar with it.
• Your C sources should have already been modified according to instructions given earlier in this manual. See section Preparing Program Sources.
• Your ‘po/’ directory should receive all PO files submitted to you by the translator teams, each having ‘ll.po’ as a name. This is not usually easy to get translation work done before your package gets internationalized and available! Since the cycle has to start somewhere, the easiest for the maintainer is to start with absolutely no PO files, and wait until various translator teams get interested in your package, and submit PO files.

It is worth adding here a few words about how the maintainer should ideally behave with PO files submissions. As a maintainer, your role is to authenticate the origin of the submission as being the representative of the appropriate translating teams of the Translation Project (forward the submission to ‘coordinator@translationproject.org’ in case of doubt), to ensure that the PO file format is not severely broken and does not prevent successful installation, and for the rest, to merely put these PO files in ‘po/’ for distribution.

As a maintainer, you do not have to take on your shoulders the responsibility of checking if the translations are adequate or complete, and should avoid diving into linguistic matters. Translation teams drive themselves and are fully responsible of their linguistic choices for the Translation Project. Keep in mind that translator teams are not driven by maintainers. You can help by carefully redirecting all communications and reports from users about linguistic matters to the appropriate translation team, or explain users how to reach or join their team. The simplest might be to send them the ‘ABOUT-NLS’ file.

Maintainers should never ever apply PO file bug reports themselves, short-cutting translation teams. If some translator has difficulty to get some of her points through her team, it should not be an option for her to directly negotiate translations with maintainers. Teams ought to settle their problems themselves, if any. If you, as a maintainer, ever think there is a real problem with a team, please never try to solve a team’s problem on your own.

This document was generated on June 7, 2014 using texi2html 5.0.