grub-lakitu/ABOUT-NLS - cos/cobble - Git at Google

 1 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 free software 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 on translations can 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.

 1.1 Quick configuration advice
 ==============================

 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, message inheritance, automatic
 charset conversion or plural form handling) 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'.

 1.2 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 already
 provides the GNU `gettext' functions.  If not, the included GNU
 `gettext' 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 --disable-nls

 will, respectively, bypass any pre-existing `gettext' to use the
 internationalizing routines provided within this package, 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 not be 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.

    The configuration process will not test for the `catgets' function
 and therefore it will not be used.  The reason is that even an
 emulation of `gettext' on top of `catgets' could not provide all the
 extensions of the GNU `gettext' library.

    Internationalized packages usually have 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.

 1.3 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
 `LL_CC' combination.  Here `LL' is an ISO 639 two-letter language code,
 and `CC' is an ISO 3166 two-letter country code.  For example, let's
 suppose that you speak German and live in Germany.  At the shell
 prompt, merely execute `setenv LANG de_DE' (in `csh'),
 `export LANG; LANG=de_DE' (in `sh') or `export LANG=de_DE' (in `bash').
 This can be done from your `.login' or `.profile' file, once and for
 all.

    You might think that the country code specification is redundant.
 But in fact, some languages have dialects in different countries.  For
 example, `de_AT' is used for Austria, and `pt_BR' for Brazil.  The
 country code serves to distinguish the dialects.

    The locale naming convention of `LL_CC', with `LL' denoting the
 language and `CC' denoting the country, is the one use on systems based
 on GNU libc.  On other systems, some variations of this scheme are
 used, such as `LL' or `LL_CC.ENCODING'.  You can get the list of
 locales supported by your system for your language by running the
 command `locale -a | grep '^LL''.

    Not all programs have translations for all languages.  By default, an
 English message is shown in place of a nonexistent translation.  If you
 understand other languages, you can set up a priority list of languages.
 This is done through a different environment variable, called
 `LANGUAGE'.  GNU `gettext' gives preference to `LANGUAGE' over `LANG'
 for the purpose of message handling, but you still need to have `LANG'
 set to the primary language; this is required by other parts of the
 system libraries.  For example, some Swedish users who would rather
 read translations in German than English for when Swedish is not
 available, set `LANGUAGE' to `sv:de' while leaving `LANG' to `sv_SE'.

    Special advice for Norwegian users: The language code for Norwegian
 bokma*l changed from `no' to `nb' recently (in 2003).  During the
 transition period, while some message catalogs for this language are
 installed under `nb' and some older ones under `no', it's recommended
 for Norwegian users to set `LANGUAGE' to `nb:no' so that both newer and
 older translations are used.

    In the `LANGUAGE' environment variable, but not in the `LANG'
 environment variable, `LL_CC' combinations can be abbreviated as `LL'
 to denote the language's main dialect.  For example, `de' is equivalent
 to `de_DE' (German as spoken in Germany), and `pt' to `pt_PT'
 (Portuguese as spoken in Portugal) in this context.

 1.4 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.  The up-to-date list of
 teams can be found at the Free Translation Project's homepage,
 `http://www.iro.umontreal.ca/contrib/po/HTML/', in the "National teams"
 area.

    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 skills are praised more than
 programming skills, here.

 1.5 Available Packages
 ======================

 Languages are not equally supported in all packages.  The following
 matrix shows the current state of internationalization, as of October
 2006.  The matrix shows, in regard of each package, for which languages
 PO files have been submitted to translation coordination, with a
 translation percentage of at least 50%.

 # Matrix here is removed!

    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 October 2006 seems to be old, you may fetch a more recent copy of
 this `ABOUT-NLS' file on most GNU archive sites.  The most up-to-date
 matrix with full percentage details can be found at
 `http://www.iro.umontreal.ca/contrib/po/HTML/matrix.html'.

 1.6 Using `gettext' in new packages
 ===================================

 If you are writing a freely available program and want to
 internationalize it you are welcome to use GNU `gettext' in your
 package.  Of course you have to respect the GNU Library General Public
 License which covers the use of the GNU `gettext' library.  This means
 in particular that even non-free programs can use `libintl' as a shared
 library, whereas only free software can use `libintl' as a static
 library or use modified versions of `libintl'.

    Once the sources are changed appropriately and the setup can handle
 the use of `gettext' the only thing missing are the translations.  The
 Free Translation Project is also available for packages which are not
 developed inside the GNU project.  Therefore the information given above
 applies also for every other Free Software Project.  Contact
 `translation@iro.umontreal.ca' to make the `.pot' files available to
 the translation teams.
	1 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 free software 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 on translations can 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.

	1.1 Quick configuration advice
	==============================

	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, message inheritance, automatic
	charset conversion or plural form handling) 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'.

	1.2 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 already
	provides the GNU `gettext' functions. If not, the included GNU
	`gettext' 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 --disable-nls

	will, respectively, bypass any pre-existing `gettext' to use the
	internationalizing routines provided within this package, 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 not be 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.

	The configuration process will not test for the `catgets' function
	and therefore it will not be used. The reason is that even an
	emulation of `gettext' on top of `catgets' could not provide all the
	extensions of the GNU `gettext' library.

	Internationalized packages usually have 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.

	1.3 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
	`LL_CC' combination. Here `LL' is an ISO 639 two-letter language code,
	and `CC' is an ISO 3166 two-letter country code. For example, let's
	suppose that you speak German and live in Germany. At the shell
	prompt, merely execute `setenv LANG de_DE' (in `csh'),
	`export LANG; LANG=de_DE' (in `sh') or `export LANG=de_DE' (in `bash').
	This can be done from your `.login' or `.profile' file, once and for
	all.

	You might think that the country code specification is redundant.
	But in fact, some languages have dialects in different countries. For
	example, `de_AT' is used for Austria, and `pt_BR' for Brazil. The
	country code serves to distinguish the dialects.

	The locale naming convention of `LL_CC', with `LL' denoting the
	language and `CC' denoting the country, is the one use on systems based
	on GNU libc. On other systems, some variations of this scheme are
	used, such as `LL' or `LL_CC.ENCODING'. You can get the list of
	locales supported by your system for your language by running the
	command `locale -a \| grep '^LL''.

	Not all programs have translations for all languages. By default, an
	English message is shown in place of a nonexistent translation. If you
	understand other languages, you can set up a priority list of languages.
	This is done through a different environment variable, called
	`LANGUAGE'. GNU `gettext' gives preference to `LANGUAGE' over `LANG'
	for the purpose of message handling, but you still need to have `LANG'
	set to the primary language; this is required by other parts of the
	system libraries. For example, some Swedish users who would rather
	read translations in German than English for when Swedish is not
	available, set `LANGUAGE' to `sv:de' while leaving `LANG' to `sv_SE'.

	Special advice for Norwegian users: The language code for Norwegian
	bokma*l changed from `no' to `nb' recently (in 2003). During the
	transition period, while some message catalogs for this language are
	installed under `nb' and some older ones under `no', it's recommended
	for Norwegian users to set `LANGUAGE' to `nb:no' so that both newer and
	older translations are used.

	In the `LANGUAGE' environment variable, but not in the `LANG'
	environment variable, `LL_CC' combinations can be abbreviated as `LL'
	to denote the language's main dialect. For example, `de' is equivalent
	to `de_DE' (German as spoken in Germany), and `pt' to `pt_PT'
	(Portuguese as spoken in Portugal) in this context.

	1.4 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. The up-to-date list of
	teams can be found at the Free Translation Project's homepage,
	`http://www.iro.umontreal.ca/contrib/po/HTML/', in the "National teams"
	area.

	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 skills are praised more than
	programming skills, here.

	1.5 Available Packages
	======================

	Languages are not equally supported in all packages. The following
	matrix shows the current state of internationalization, as of October
	2006. The matrix shows, in regard of each package, for which languages
	PO files have been submitted to translation coordination, with a
	translation percentage of at least 50%.

	# Matrix here is removed!

	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 October 2006 seems to be old, you may fetch a more recent copy of
	this `ABOUT-NLS' file on most GNU archive sites. The most up-to-date
	matrix with full percentage details can be found at
	`http://www.iro.umontreal.ca/contrib/po/HTML/matrix.html'.

	1.6 Using `gettext' in new packages
	===================================

	If you are writing a freely available program and want to
	internationalize it you are welcome to use GNU `gettext' in your
	package. Of course you have to respect the GNU Library General Public
	License which covers the use of the GNU `gettext' library. This means
	in particular that even non-free programs can use `libintl' as a shared
	library, whereas only free software can use `libintl' as a static
	library or use modified versions of `libintl'.

	Once the sources are changed appropriately and the setup can handle
	the use of `gettext' the only thing missing are the translations. The
	Free Translation Project is also available for packages which are not
	developed inside the GNU project. Therefore the information given above
	applies also for every other Free Software Project. Contact
	`translation@iro.umontreal.ca' to make the `.pot' files available to
	the translation teams.