When GNU 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 Translation Project.
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
gettext
, one 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 for ll.
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 this GNU 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 gettext
,
internally, 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 the GNU gettext
functions. If
not, the GNU 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 gettext
to use the included GNU
gettext
instead, while `./configure
--disable-nls´ produces programs totally unable to
translate messages.
Internationalized packages
have usually many `ll.po´ files. Unless
translations are disabled, all those available are installed
together with the package. However, the environment variable
LINGUAS
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 gettext
internally, and for which
the installers did not disable translation at configure
time. Then, users only have to set the LANG
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 csh
) or
`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.