@node Translation Intro
@chapter Notes on the GNU Translation Project

@set STATUS August 1996

GNU is going international!  The GNU Translation Project is a way to get
maintainers, translators, and users all together, so that GNU will
gradually become able to speak many languages.  A few packages already
provide translations for their messages.

If you found this @file{ABOUT-NLS} file inside a GNU distribution, you
may assume that the distributed package does use GNU @code{gettext}
internally, itself available at your nearest GNU archive site.  But you
do @emph{not} need to install GNU @code{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 @file{intl/} directory or bugs which may
be related to internationalization, you should tell about the version
of @code{gettext} which is used.  The information can be found in
the @file{intl/VERSION} file, in internationalized packages.

@menu
* One advise::
* INSTALL Matters::
* Using This Package::
* Translating Teams::
* Available Packages::
@end menu

@node One advise
@section One advise in advance

If you want to exploit the full power of internationalization, you
should configure it using

@example
./configure --with-included-gettext
@end example

@noindent
to force usage of internationalizing routines provided within this
package, despite the existence of internationalizing capabilities in
the operating system where this package is being installed.  So far, no
prior implementation provides as many useful features (such as locale
alias or message inheritance).  It is also not possible to offer this
additional functionality on top of a @code{catgets} implementation.
Future versions of GNU @code{gettext} will very likely convey even
more functionality.  So it might be a good idea to change to GNU
@code{gettext} as soon as possible.


@node INSTALL Matters
@section INSTALL Matters

Some GNU packages are @dfn{localizable} when properly installed; the
programs they contain can be made to speak your own native language.
Most such packages use GNU @code{gettext}.  Other packages have their
own ways to internationalization, predating GNU @code{gettext}.

By default, this package will be installed to allow translation of
messages.  It will automatically detect whether the system provides
usable @code{catgets} (if using this is selected by the installer) or
@code{gettext} functions.  If neither is available, the GNU
@code{gettext} own library will be used.  This library is wholly
contained within this package, usually in the @file{intl/} subdirectory,
so prior installation of the GNU @code{gettext} package is @emph{not}
required.  Installers may use special options at configuration time for
changing the default behaviour.  The commands:

@example
./configure --with-included-gettext
./configure --with-catgets
./configure --disable-nls
@end example

@noindent
will respectively bypass any pre-existing @code{catgets} or
@code{gettext} to use the internationalizing routines provided within
this package, enable the use of the @code{catgets} functions (if found
on the locale system), or else, @emph{totally} disable translation of
messages.

When you already have GNU @code{gettext} installed on your system and
run configure without an option for your new package, @code{configure}
will probably detect the previously built and installed @file{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 @code{gettext}
library.  I.e. if the file @file{intl/VERSION} shows that the library
which comes with this package is more recent, you should use

@example
./configure --with-included-gettext
@end example

@noindent
to prevent auto-detection.

By default the configuration process will not test for the
@code{catgets} function and therefore they will not be used.  The
reasons are already given above: the emulation on top of @code{catgets}
cannot provide all the extensions provided by the GNU @code{gettext}
library.  If you nevertheless want to use the @code{catgets} functions
use

@example
./configure --with-catgets
@end example

@noindent
to enable the test for @code{catgets} (this causes no harm if
@code{catgets} is not available on your system).  If you really select
this option we would like to hear about the reasons because we cannot
think of any good one ourself.

Internationalized packages have usually many @file{po/@var{ll}.po}
files, where @var{ll} gives an @w{ISO 639} two-letter code
identifying the language.  Unless translations have been forbidden
at @code{configure} time by using the @samp{--disable-nls} switch,
all available translations are installed together with the package.
However, the environment variable @code{LINGUAS} may be set, prior
to configuration, to limit the installed set.  @code{LINGUAS} should
then contain a space separated list of two-letter codes, stating
which languages are allowed.

@node Using This Package
@section Using This Package

@c --
@c FIXME: rewrite to document LANGUAGE, the long names, and aliases.
@c --
As a user, if your language has been installed for this package, you
only have to set the @code{LANG} environment variable to the appropriate
@w{ISO 639} @samp{@var{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 @w{@samp{setenv LANG de}} (in
@code{csh}), @w{@samp{export LANG; LANG=de}} (in @code{sh}) or
@w{@samp{export LANG=de}} (in @code{bash}).  This can be done from your
@file{.login} or @file{.profile} file, once and for all.
@c Packages which are not internationalized will merely ignore the
@c setting of this variable.
@c FIXME: This last sentence is not true!! --drepper

An operating system might already offer message localization for many of
its programs, while other programs (whether GNU or not) have been
installed locally with the full capabilities of GNU @code{gettext}.
Just using @code{gettext} extended syntax for @code{LANG} would break
proper localization of already available operating system programs.  In
this case, users should set both @code{LANGUAGE} and @code{LANG}
variables in their environment, as programs using GNU @code{gettext}
give preference to @code{LANGUAGE}.  For example, some Swedish users
would rather read translations in German than English for when Swedish
is not available.  This is easily accomplished by setting
@code{LANGUAGE} to @samp{sv:de} while leaving @code{LANG} to @samp{sv}.


@node Translating Teams
@section Translating Teams

For the GNU Translation Project to be a success, we need 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 translation team has its own mailing list, courtesy of Linux
International.  You may reach your translation team at the address
@file{@var{ll}@@li.org}, replacing @var{ll} by the two-letter @w{ISO
639} code for your language.  Language codes are @emph{not} the same as
the country codes given in @w{ISO 3166}.  The following translation
teams exist, as of @value{STATUS}:

@quotation
Arabic @code{ar}, Chinese @code{zh}, Czech @code{cs}, Danish @code{da},
Dutch @code{nl}, English @code{en}, Esperanto @code{eo}, Finnish
@code{fi}, French @code{fr}, German @code{de}, Greek @code{el}, Hebrew
@code{he}, Hungarian @code{hu}, Irish @code{ga}, Italian @code{it},
Indonesian @code{id}, Japanese @code{ja}, Korean @code{ko}, Latin
@code{la}, Norwegian @code{no}, Persian @code{fa}, Polish @code{pl},
Portuguese @code{pt}, Russian @code{ru}, Slovenian @code{sl}, Spanish
@code{es}, Swedish @code{sv}, Telugu @code{te}, Turkish @code{tr} and
Ukrainian @code{uk}.
@end quotation

@noindent
For example, you may reach the Chinese translation team by writing to
@file{zh@@li.org}.

If you'd like to volunteer to @emph{work} at translating messages, you
should become a member of the translating team for your own language.
The subscribing address is @emph{not} the same as the list itself, it
has @samp{-request} appended.  For example, speakers of Swedish can send
a message to @w{@file{sv-request@@li.org}}, having this message body:

@example
subscribe
@end example

Keep in mind that team members are expected to participate
@emph{actively} in translations, or at solving translational
difficulties, rather than merely lurking around.  If your team does not
exist yet and you want to start one, or if you are unsure about what to
do or how to get started, please write to
@w{@file{gnu-translation@@gnu.ai.mit.edu}} to 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 explicitly invited to do so.

@node Available Packages
@section Available Packages

Languages are not equally supported in all GNU packages.  The following
matrix shows the current state of GNU internationalization, as of
@value{STATUS}.  The matrix shows, in regard of each package, for which
languages PO files have been submitted to translation coordination.

@include matrix.texi

Some counters in the preceding matrix are higher than the number of visible
blocks let us expect.  This is because a few extra PO files are used for
implementing regional variants of languages, or language dialects.

For a PO file in the matrix above to be effective, the package to which
it applies should also have been internationalized and distributed as
such by its maintainer.  There might be an observable lag between the
mere existence a PO file and its wide availability in a GNU distribution.

If @value{STATUS} seems to be old, you may fetch a more recent copy
of this @file{ABOUT-NLS} file on most GNU archive sites.
