~ubuntu-branches/ubuntu/oneiric/gconf/oneiric-proposed

Notes on the Free Translation Project

*************************************

   Free software is going international!  The Free Translation Project

is a way to get maintainers of free software, translators, and users all

together, so that will gradually become able to speak many languages.

A few packages already provide translations for their messages.

   If you found this `ABOUT-NLS' file inside a 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 internationalization, you

should configure it using

     ./configure --with-included-gettext

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, only

the `gettext' implementation in the GNU C library version 2 provides as

many features (such as locale alias or message inheritance) as the

implementation here.  It is also not possible to offer this additional

functionality on top of a `catgets' implementation.  Future versions of

GNU `gettext' will very likely convey even more functionality.  So it

might be a good idea to change to GNU `gettext' as soon as possible.

   So you need not provide this option if you are using GNU libc 2 or

you have installed a recent copy of the GNU gettext package with the

included `libintl'.

INSTALL Matters

===============

   Some 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' (if using this is selected by the installer) or

`gettext' functions.  If neither is available, the GNU `gettext' own

library will be used.  This library is wholly contained within this

package, usually in the `intl/' subdirectory, so prior installation of

the GNU `gettext' package is *not* required.  Installers may use

special options at configuration time for changing the default

behaviour.  The commands:

     ./configure --with-included-gettext

     ./configure --with-catgets

     ./configure --disable-nls

will respectively bypass any pre-existing `catgets' or `gettext' to use

the internationalizing routines provided within this package, enable

the use of the `catgets' functions (if found on the locale system), 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

     ./configure --with-included-gettext

to prevent auto-detection.

   By default the configuration process will not test for the `catgets'

function and therefore they will not be used.  The reasons are already

given above: the emulation on top of `catgets' cannot provide all the

extensions provided by the GNU `gettext' library.  If you nevertheless

want to use the `catgets' functions use

     ./configure --with-catgets

to enable the test for `catgets' (this causes no harm if `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 `po/LL.po' files, where

LL gives an ISO 639 two-letter code identifying the language.  Unless

translations have been forbidden at `configure' time by using the

`--disable-nls' switch, all available translations 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'),

`export LANG; LANG=de' (in `sh') or `export LANG=de' (in `bash').  This

can be done from your `.login' or `.profile' file, once and for all.

   An operating system might already offer message localization for

many of its programs, while other programs have been installed locally

with the full capabilities of GNU `gettext'.  Just using `gettext'

extended syntax for `LANG' would break proper localization of already

available operating system programs.  In this case, users should set

both `LANGUAGE' and `LANG' variables in their environment, as programs

using GNU `gettext' give preference to `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

`LANGUAGE' to `sv:de' while leaving `LANG' to `sv'.

Translating Teams

=================

   For the Free 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

`LL@li.org', replacing LL by the two-letter ISO 639 code for your

language.  Language codes are *not* the same as the country codes given

in ISO 3166.  The following translation teams exist, as of December

1997:

     Chinese `zh', Czech `cs', Danish `da', Dutch `nl', English `en',

     Esperanto `eo', Finnish `fi', French `fr', German `de', Hungarian

     `hu', Irish `ga', Italian `it', Indonesian `id', Japanese `ja',

     Korean `ko', Latin `la', Norwegian `no', Persian `fa', Polish

     `pl', Portuguese `pt', Russian `ru', Slovenian `sl', Spanish `es',

     Swedish `sv', and Turkish `tr'.

For example, you may reach the Chinese translation team by writing to

`zh@li.org'.

   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, speakers of Swedish can send a

message to `sv-request@li.org', having this message body:

     subscribe

   Keep in mind that team members are expected to participate

*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 `translation@iro.umontreal.ca' to reach the

coordinator for all translator teams.

   The English team is special.  It works at improving and uniformizing

the terminology in use.  Proven linguistic skill are praised more than

programming skill, here.

Available Packages

==================

   Languages are not equally supported in all packages.  The following

matrix shows the current state of internationalization, as of December

1997.  The matrix shows, in regard of each package, for which languages

PO files have been submitted to translation coordination.

     Ready PO files    cs da de en es fi fr it ja ko nl no pl pt ru sl sv

                     .----------------------------------------------------.

     bash            |       []          []          []                   |  3

     bison           |       []          []          []                   |  3

     clisp           |       [] [] []    []                               |  4

     cpio            |       []    []    []       [] []    []             |  6

     diffutils       |       []    []    []                []          [] |  5

     enscript        |       []    [] [] []          []             []    |  6

     fileutils       | []    []    []    []       [] []    [] []    [] [] | 10

     findutils       |       []    []    [] []    [] []    []    []    [] |  9

     flex            |             []    []       []                   [] |  4

     gcal            |       []          []          []    []          [] |  5

     gettext         |    [] []    []    []       [] [] [] [] []    [] [] | 12

     grep            |       []    []    []       [] [] [] []    [] [] [] | 10

     hello           |    [] []    []    []       [] [] [] [] []    [] [] | 11

     id-utils        |       []          []                []             |  3

     indent          |    [] []                   []       []    []       |  5

     libc            |       []    []    []       [] []    []          [] |  7

     m4              |       []          []    []    []          []    [] |  6

     make            |       []    []    []       [] []    []             |  6

     music           |                   []                []             |  2

     ptx             |       []    []    []          [] [] [] []       [] |  8

     recode          |    [] []    []    []          []    [] []    [] [] |  9

     sh-utils        |       []    []    []          [] [] [] []       [] |  8

     sharutils       | []    []    []    []          []                [] |  6

     tar             | []    []          [] []    [] [] [] [] []    [] [] | 11

     texinfo         | []    []          []                               |  3

     textutils       | []    []    []    []       [] [] [] []          [] |  9

     wdiff           | []    []    []    []          [] [] []          [] |  8

                     `----------------------------------------------------'

       17 languages    cs da de en es fi fr it ja ko nl no pl pt ru sl sv

       27 packages      6  4 25  1 18  1 26  2  1 12 20  9 19  7  4  7 17  179

   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

distribution.

   If December 1997 seems to be old, you may fetch a more recent copy

of this `ABOUT-NLS' file on most GNU archive sites.