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. + +