summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJim Meyering <jim@meyering.net>1996-04-02 15:57:23 +0000
committerJim Meyering <jim@meyering.net>1996-04-02 15:57:23 +0000
commit834a0cf02360aadeb03667fb4f74307d6ded65ca (patch)
treee1b1909981188e870bde0be7daa36beec392ced4
parent778abcac1ec6c614b8d3171000cc525e074ca7fd (diff)
downloadcoreutils-834a0cf02360aadeb03667fb4f74307d6ded65ca.tar.xz
.
-rw-r--r--ABOUT-NLS219
1 files changed, 219 insertions, 0 deletions
diff --git a/ABOUT-NLS b/ABOUT-NLS
new file mode 100644
index 000000000..1d7309be4
--- /dev/null
+++ b/ABOUT-NLS
@@ -0,0 +1,219 @@
+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 internationalization, you
+should configure it using
+
+ ./configure --with-gnu-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, 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 `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.
+
+INSTALL Matters
+===============
+
+ 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. 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-gnu-gettext
+ ./configure --disable-nls
+
+will respectively bypass any pre-existing `catgets' or `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 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-gnu-gettext
+
+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 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 (whether GNU or not) 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
+=================
+
+ 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
+internationalized.
+
+ 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 January 1996:
+
+ 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
+ `tr'.
+
+For example, you may reach the Chinese translating 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, Swedish people can send a message to
+`sv-request@li.org', having this message body:
+
+ subscribe
+
+ 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 `gnu-translation@gnu.ai.mit.edu'; 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.
+
+Available Packages
+==================
+
+ Languages are not equally supported in all GNU packages. The
+following matrix shows the current state of GNU internationalization,
+as of January 1996. Listed are: internationalized packages, and
+languages for which work is in progress, or about to start.
+
+ See note cs de en fr it ja ko nl no pl 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 ko nl no pl 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
+ progress.
+
+`-'
+ 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.
+
+`X'
+ The localization of this package to this particular language is
+ fully completed, and now distributed through an official release.
+
+(1)
+ 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.
+
+(2)
+ This package is planned to switch to GNU `gettext'. For the time
+ being, it uses temporary means for internationalization.
+
+(3)
+ This package has its translatable strings marked, but does not use
+ GNU `gettext'. A convenience patch may be available separately.
+
+ If January 1996 seems to be old, you may fetch a more recent copy of
+this `ABOUT-NLS' file on most GNU archive sites.
+