gettext will truly have reached its goal, average users
should feel some kind of astonished pleasure, seeing the effect of
that strange kind of magic that just makes their own native language
appear everywhere on their screens. As for naive users, they would
ideally have no special pleasure about it, merely taking their own
language for granted, and becoming rather unhappy otherwise.
So, let's try to describe here how we would like the magic to operate,
as we want the users' view to be the simplest, among all ways one
could look at GNU
gettext. All other software engineers:
programmers, translators, maintainers, should work together in such a
way that the magic becomes possible. This is a long and progressive
undertaking, and information is available about the progress of the
When a package is distributed, there are two kinds of users:
installers who fetch the distribution, unpack it, configure
it, compile it and install it for themselves or others to use; and
end users that call programs of the package, once these have
been installed at their site. GNU
gettext is offering magic
for both installers and end users.
Languages are not equally supported in all packages using GNU
gettext. To know if some package uses GNU
may check the distribution for the `ABOUT-NLS´ information file, for
some `ll.po´ files, often kept together into some `po/´
directory, or for an `intl/´ directory. Internationalized packages
have usually many `ll.po´ files, where ll represents
the language. section 9.3 Magic for End Users for a complete description of the format
More generally, a matrix is available for showing the current state
of the Translation Project, listing which packages are prepared for
multi-lingual messages, and which languages are supported by each.
Because this information changes often, this matrix is not kept within
gettext manual. This information is often found in
file `ABOUT-NLS´ from various distributions, but is also as old as
the distribution itself. A recent copy of this `ABOUT-NLS´ file,
containing up-to-date information, should generally be found on the
Translation Project sites, and also on most GNU archive sites.
By default, packages fully using GNU
are installed in such a way that they to allow translation of
messages. At configuration time, those packages should
automatically detect whether the underlying host system already provides
gettext functions. If not,
gettext library should be automatically prepared
and used. Installers may use special options at configuration
time for changing this behavior. The command `./configure
--with-included-gettext´ bypasses system
use the included GNU
while `./configure --disable-nls´
produces programs totally unable to translate messages.
Internationalized packages have usually many `ll.po´
translations are disabled, all those available are installed together
with the package. However, the environment variable
may be set, prior to configuration, to limit the installed set.
LINGUAS should then contain a space separated list of two-letter
codes, stating which languages are allowed.
We consider here those packages using GNU
and for which the installers did not disable translation at
configure time. Then, users only have to set the
environment variable to the appropriate `ll_CC´
combination prior to using the programs in the package. See section 9.1 The Current `ABOUT-NLS´ Matrix.
For example, let's presume a German site. At the shell prompt, users
merely have to execute `setenv LANG de_DE´ (in
`export LANG; LANG=de_DE´ (in
sh). They could even do
this from their `.login´ or `.profile´ file.
Go to the first, previous, next, last section, table of contents.