Go to the first, previous, next, last section, table of contents.
The maintainer of a package has many responsibilities. One of them is ensuring that the package will install easily on many platforms, and that the magic we described earlier (see section The User's View) will work for installers and end users.
Of course, there are many possible ways by which GNU gettext
might be integrated in a distribution, and this chapter does not cover
them in all generality. Instead, it details one possible approach which
is especially adequate for many free software distributions following GNU
standards, or even better, Gnits standards, because GNU gettext
is purposely for helping the internationalization of the whole GNU
project, and as many other good free packages as possible. So, the
maintainer's view presented here presumes that the package already has
a `configure.in' file and uses GNU Autoconf.
Nevertheless, GNU gettext may surely be useful for free packages
not following GNU standards and conventions, but the maintainers of such
packages might have to show imagination and initiative in organizing
their distributions so gettext work for them in all situations.
There are surely many, out there.
Even if gettext methods are now stabilizing, slight adjustments
might be needed between successive gettext versions, so you
should ideally revise this chapter in subsequent releases, looking
for changes.
Some free software packages are distributed as tar files which unpack
in a single directory, these are said to be flat distributions.
Other free software packages have a one level hierarchy of subdirectories, using
for example a subdirectory named `doc/' for the Texinfo manual and
man pages, another called `lib/' for holding functions meant to
replace or complement C libraries, and a subdirectory `src/' for
holding the proper sources for the package. These other distributions
are said to be non-flat.
For now, we cannot say much about flat distributions. A flat
directory structure has the disadvantage of increasing the difficulty
of updating to a new version of GNU gettext. Also, if you have
many PO files, this could somewhat pollute your single directory.
In the GNU gettext distribution, the `misc/' directory
contains a shell script named `combine-sh'. That script may
be used for combining all the C files of the `intl/' directory
into a pair of C files (one `.c' and one `.h'). Those two
generated files would fit more easily in a flat directory structure,
and you will then have to add these two files to your project.
Maybe because GNU gettext itself has a non-flat structure,
we have more experience with this approach, and this is what will be
described in the remaining of this chapter. Some maintainers might
use this as an opportunity to unflatten their package structure.
Only later, once gained more experience adapting GNU gettext
to flat distributions, we might add some notes about how to proceed
in flat situations.
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.
m4, GNU Autoconf and GNU
gettext are already installed at your site, and if not, proceed
to do this first. If you got 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 to 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.
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 authentify the origin of the submission as being the representative of the appropriate translating teams of the Translation Project (forward the submission to `translation@iro.umontreal.ca' 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 to pstay aware of normalisation issues.
Go to the first, previous, next, last section, table of contents.