gettext: Prerequisites
1
1 13.2 Prerequisite Works
1 =======================
1
1 There are some works which are required for using GNU ‘gettext’ in
1 one of your package. These works have some kind of generality that
1 escape the point by point descriptions used in the remainder of this
1 chapter. So, we describe them here.
1
1 • Before attempting to use ‘gettextize’ you should install some other
1 packages first. Ensure that recent versions of GNU ‘m4’, GNU
1 Autoconf and GNU ‘gettext’ are already installed at your site, and
1 if not, proceed to do this first. If you get to install these
1 things, beware that GNU ‘m4’ must be fully installed before GNU
1 Autoconf is even _configured_.
1
1 To further ease the task of a package maintainer the ‘automake’
1 package was designed and implemented. GNU ‘gettext’ now uses this
1 tool and the ‘Makefile’s in the ‘intl/’ and ‘po/’ therefore know
1 about all the goals necessary for using ‘automake’ and ‘libintl’ in
1 one project.
1
1 Those four packages are only needed by you, as a maintainer; the
1 installers of your own package and end users do not really need any
1 of GNU ‘m4’, GNU Autoconf, GNU ‘gettext’, or GNU ‘automake’ for
1 successfully installing and running your package, with messages
1 properly translated. But this is not completely true if you
1 provide internationalized shell scripts within your own package:
1 GNU ‘gettext’ shall then be installed at the user site if the end
1 users want to see the translation of shell script messages.
1
1 • Your package should use Autoconf and have a ‘configure.ac’ or
1 ‘configure.in’ file. If it does not, you have to learn how. The
1 Autoconf documentation is quite well written, it is a good idea
1 that you print it and get familiar with it.
1
1 • Your C sources should have already been modified according to
1 instructions given earlier in this manual. ⇒Sources.
1
1 • Your ‘po/’ directory should receive all PO files submitted to you
1 by the translator teams, each having ‘LL.po’ as a name. This is
1 not usually easy to get translation work done before your package
1 gets internationalized and available! Since the cycle has to start
1 somewhere, the easiest for the maintainer is to start with
1 absolutely no PO files, and wait until various translator teams get
1 interested in your package, and submit PO files.
1
1 It is worth adding here a few words about how the maintainer should
1 ideally behave with PO files submissions. As a maintainer, your role is
1 to authenticate the origin of the submission as being the representative
1 of the appropriate translating teams of the Translation Project (forward
1 the submission to ‘coordinator@translationproject.org’ in case of
1 doubt), to ensure that the PO file format is not severely broken and
1 does not prevent successful installation, and for the rest, to merely
1 put these PO files in ‘po/’ for distribution.
1
1 As a maintainer, you do not have to take on your shoulders the
1 responsibility of checking if the translations are adequate or complete,
1 and should avoid diving into linguistic matters. Translation teams
1 drive themselves and are fully responsible of their linguistic choices
1 for the Translation Project. Keep in mind that translator teams are
1 _not_ driven by maintainers. You can help by carefully redirecting all
1 communications and reports from users about linguistic matters to the
1 appropriate translation team, or explain users how to reach or join
1 their team. The simplest might be to send them the ‘ABOUT-NLS’ file.
1
1 Maintainers should _never ever_ apply PO file bug reports themselves,
1 short-cutting translation teams. If some translator has difficulty to
1 get some of her points through her team, it should not be an option for
1 her to directly negotiate translations with maintainers. Teams ought to
1 settle their problems themselves, if any. If you, as a maintainer, ever
1 think there is a real problem with a team, please never try to _solve_ a
1 team’s problem on your own.
1