Go to the first, previous, next, last section, table of contents. -
- - -
-When GNU gettext will truly have reached is goal, average users
-should feel some kind of astonished pleasure, seeing the effect of
-that strange kind of magic that just makes their own native language
-appear everywhere on their screens. As for naive users, they would
-ideally have no special pleasure about it, merely taking their own
-language for granted, and becoming rather unhappy otherwise.
-
-
-So, let's try to describe here how we would like the magic to operate,
-as we want the users' view to be the simplest, among all ways one
-could look at GNU gettext. All other software engineers:
-programmers, translators, maintainers, should work together in such a
-way that the magic becomes possible. This is a long and progressive
-undertaking, and information is available about the progress of the
-Translation Project.
-
-
-When a package is distributed, there are two kind of users:
-installers who fetch the distribution, unpack it, configure
-it, compile it and install it for themselves or others to use; and
-end users that call programs of the package, once these have
-been installed at their site. GNU gettext is offering magic
-for both installers and end users.
-
-
-Languages are not equally supported in all packages using GNU
-gettext. To know if some package uses GNU gettext, one
-may check the distribution for the `ABOUT-NLS' information file, for
-some `ll.po' files, often kept together into some `po/'
-directory, or for an `intl/' directory. Internationalized packages
-have usually many `ll.po' files, where ll represents
-the language. section Magic for End Users for a complete description of the format
-for ll.
-
-
-More generally, a matrix is available for showing the current state
-of the Translation Project, listing which packages are prepared for
-multi-lingual messages, and which languages is supported by each.
-Because this information changes often, this matrix is not kept within
-this GNU gettext manual. This information is often found in
-file `ABOUT-NLS' from various distributions, but is also as old as
-the distribution itself. A recent copy of this `ABOUT-NLS' file,
-containing up-to-date information, should generally be found on the
-Translation Project sites, and also on most GNU archive sites.
-
-
-By default, packages fully using GNU gettext, internally,
-are installed in such a way that they to allow translation of
-messages. At configuration time, those packages should
-automatically detect whether the underlying host system provides usable
-catgets or gettext functions. If neither is present,
-the GNU gettext library should be automatically prepared
-and used. Installers may use special options at configuration
-time for changing this behavior. The command `./configure
---with-included-gettext' bypasses system catgets or gettext to
-use GNU gettext instead, while `./configure --disable-nls'
-produces program totally unable to translate messages.
-
-
-Internationalized packages have usually many `ll.po'
-files. 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.
-
-
-We consider here those packages using GNU gettext internally,
-and for which the installers did not disable translation at
-configure time. Then, users only have to set the LANG
-environment variable to the appropriate `ll' prior to
-using the programs in the package. See section The Current `ABOUT-NLS' Matrix. For example,
-let's presume a German site. At the shell prompt, users merely have to
-execute `setenv LANG de' (in csh) or `export
-LANG; LANG=de' (in sh). They could even do this from their
-`.login' or `.profile' file.
-
-
-
Go to the first, previous, next, last section, table of contents. - -