gettext: Prerequisites
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’ in the ‘po/’ directory therefore knows
about all the goals necessary for using ‘automake’.
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. ⇒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.
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.
Info Catalog
gettext: Flat and Non-Flat
gettext: Maintainers
gettext: gettextize Invocation