Notes on the GNU Translation Project
GNU is going international! The GNU Translation Project is a way to
get maintainers, translators and users all together, so GNU will
gradually become able to speak many native languages. A few packages
already provide native language translation for their messages.
If you found this `ABOUT-NLS' file inside a GNU distribution, you
may assume that the distributed package does use GNU `gettext'
internally, itself available at your nearest GNU archive site. But you
do not need to install GNU `gettext' prior to configuring, installing
or using this package with messages translated.
Installers will find here some useful hints. These notes also
explain how users should proceed for getting the programs to use the
available translations. They tell how people wanting to contribute and
work at translations should contact the appropriate team.
When reporting bugs in the `intl/' directory or bugs which may be
related to internationalization, you should tell about the version of
`gettext' which is used. The information can be found in the
`intl/VERSION' file, in internationalized packages.
One advise in advance
If you want to exploit the full power of the GNU `gettext' package
you should configure it using
No existing implementation at this point provides so many useful
features (such as locale alias or message inheritance). It is also not
possible to provide this additional functionality on top of a catgets
Future versions of GNU `gettext' will very likely provide even more
functionality. So it might be a good idea to change to GNU `gettext'
as soon as possible.
Some GNU packages are "localizable" when properly installed; the
programs they contain can be made to speak your own native language.
Most such packages use GNU `gettext'. Other packages have their own
ways to internationalization, predating GNU `gettext'.
By default, this package will be installed to allow translation of
messages. It will automatically detect whether the system provides
usable `catgets' or `gettext' functions. If neither is available, the
GNU `gettext' own library will be used. However, installers may use
special options at configuration time for changing this behaviour. The
will respectively bypass system `catgets' or `gettext' to use GNU
`gettext', or else, totally disable translation of messages.
When you already have GNU `gettext' installed on your system and run
configure without an option for your new package, configure will
probably detect the previously built and installed `libintl.a' file and
will decide to use this. This might be not what is desirable. You
should use the more recent version of the GNU `gettext' library. I.e.
if the file `intl/VERSION' shows that the library which comes with this
package is more recent, you should use
to prevent auto-detection.
Internationalized packages have usually many `po/LL.po' files, where
LL gives an ISO 639 two-letter code identifying the language. 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.
Using This Package
As a user, if your language has been installed for this package, you
only have to set the `LANG' environment variable to the appropriate
ISO 639 `LL' two-letter code prior to using the programs in the
package. For example, let's suppose that you speak German. At the
shell prompt, merely execute `setenv LANG de' (in `csh') or
`export LANG; LANG=de' (in `sh'). This can be done from your `.login'
or `.profile' file, once and for all. Packages which are not
internationalized will merely ignore the setting of this variable.
The GNU `gettext' tool set contains *everything* maintainers need
for internationalizing their packages for messages. It also contains
quite useful tools for helping translators at localizing messages to
their native language, once a package has already been
To achieve the GNU Translation Project, we need many interested
people who like their own language and write it well, and who are also
able to synergize with other translators speaking the same language.
Each translating team has its own mailing list, courtesy of Linux
International. You may reach your translating team at the address
`LL@li.org', replacing LL by the two-letter ISO 639 code for your
language. Language codes are *not* the same as country codes given in
ISO 3166. The following translating teams exist, as of November 1995:
Chinese `zh', Czech `cs', Danish `da', Dutch `nl', English `en',
Esperanto `eo', Finnish `fi', French `fr', Irish `ga', German
`de', Greek `el', Italian `it', Japanese `ja', Indonesian `in',
Norwegian `no', Persian `fa', Polish `pl', Portuguese `pt',
Russian `ru', Spanish `es', Swedish `sv', Telugu `te' and Turkish
For example, you may reach the Chinese translating team by writing to
If you'd like to volunteer to *work* at translating messages, you
should become a member of the translating team for your own language.
The subscribing address is *not* the same as the list itself, it has
`-request' appended. For example, Swedish people can send a message to
`email@example.com', having this message body:
Keep in mind that team members should be interested in *working* at
translations, or at solving translational difficulties, rather than
merely lurking around. If your team does not exist yet and you want to
start one, please write to `firstname.lastname@example.org'; you will
then reach the GNU coordinator for all translator teams.
The English team is special. It works at improving and uniformizing
the terminology used in GNU. Proven linguistic skill are praised more
than programming skill, here. For the time being, please avoid
subscribing to the English team unless explicitely invited to do so.
Languages are not equally supported in all GNU packages. The
following matrix shows the current state of GNU internationalization,
as of November 1995. Listed are: internationalized packages, and
languages for which work is in progress, or about to start.
See note cs de en fr it ja nl no pt sv
chess (1) | X / X |
clisp | X X X |
diffutils (2) | / . |
fileutils | . / |
flex (3) | / . |
m4 | - / - - . - |
gettext | X / X X X |
ptx | - / - - |
recode | - / - - - |
sh-utils | . / . |
sharutils | X / X X X X X |
tar | X / X - X X |
textutils | . / . |
wdiff | - - / - - |
cs de en fr it ja nl no pt sv
The interpretation legend and notes are:
There is no PO file, this package merely defaults to this language.
The effort of localizing this package has been undertaken by
someone, or by a translating team, and work is, or should be in
A PO file for this package and this language is completed and is
currently available in a pretest release, or is all ready for
inclusion in the next release of this package.
The localization of this package to this particular language is
fully completed, and now distributed through an official release.
This package is translated to specific languages by methods
predating GNU `gettext'. Translations are all kept on disk files,
and sources contain numbers where one normally expects strings.
This package is planned to switch to GNU `gettext'. For the time
being, it uses temporary means for internationalization.
This package has its translatable strings marked, but does not use
GNU `gettext'. A convenience patch may be available separately.
If November 1995 seems to be old, you may fetch a more recent copy
of this `ABOUT-NLS' file on most GNU archive sites.