gettext utilities
gettext declaration
gettext Operations
gettext Installation
msgcat Program
msgconv Program
msggrep Program
msgfilter Program
msguniq Program
msgcomm Program
msgcmp Program
msgattrib Program
msgen Program
msgexec Program
msgfmt Program
msgunfmt Program
gettextize Program
gettext utilitiesThis manual documents the GNU gettext tools and the GNU libintl library, version 0.18.
--- The Detailed Node Listing ---
Introduction
The User's View
Setting the POSIX Locale
Preparing Program Sources
Making the PO Template File
Creating a New PO File
Updating Existing PO Files
Editing PO Files
Emacs's PO File Editor
Using Translation Compendia
Manipulating PO Files
Highlighting parts of PO files
Producing Binary MO Files
The Programmer's View
About catgets
About gettext
Temporary Notes for the Programmers Chapter
The Translator's View
Organization
National Teams
The Maintainer's View
Files You Must Create or Alter
Autoconf macros for use in configure.ac
Integrating with CVS
Other Programming Languages
The Translator's View
Individual Programming Languages
sh - Shell Script
Perl
Internationalizable Data
Concluding Remarks
Language Codes
Licenses
This chapter explains the goals sought in the creation
of GNU gettext and the free Translation Project.
Then, it explains a few broad concepts around
Native Language Support, and positions message translation with regard
to other aspects of national and cultural variance, as they apply
to programs. It also surveys those files used to convey the
translations. It explains how the various tools interact in the
initial generation of these files, and later, how the maintenance
cycle should usually operate.
In this manual, we use he when speaking of the programmer or
maintainer, she when speaking of the translator, and they
when speaking of the installers or end users of the translated program.
This is only a convenience for clarifying the documentation. It is
absolutely not meant to imply that some roles are more appropriate
to males or females. Besides, as you might guess, GNU gettext
is meant to be useful for people using computers, whatever their sex,
race, religion or nationality!
Please send suggestions and corrections to:
Internet address:
bug-gnu-gettext@gnu.org
Please include the manual's edition number and update date in your messages.
gettextUsually, programs are written and documented in English, and use English at execution time to interact with users. This is true not only of GNU software, but also of a great deal of proprietary and free software. Using a common language is quite handy for communication between developers, maintainers and users from all countries. On the other hand, most people are less comfortable with English than with their own native language, and would prefer to use their mother tongue for day to day's work, as far as possible. Many would simply love to see their computer screen showing a lot less of English, and far more of their own language.
However, to many people, this dream might appear so far fetched that they may believe it is not even worth spending time thinking about it. They have no confidence at all that the dream might ever become true. Yet some have not lost hope, and have organized themselves. The Translation Project is a formalization of this hope into a workable structure, which has a good chance to get all of us nearer the achievement of a truly multi-lingual set of programs.
GNU gettext is an important step for the Translation Project,
as it is an asset on which we may build many other steps. This package
offers to programmers, translators and even users, a well integrated
set of tools and documentation. Specifically, the GNU gettext
utilities are a set of tools that provides a framework within which
other free packages may produce multi-lingual messages. These tools
include
GNU gettext is designed to minimize the impact of
internationalization on program sources, keeping this impact as small
and hardly noticeable as possible. Internationalization has better
chances of succeeding if it is very light weighted, or at least,
appear to be so, when looking at program sources.
The Translation Project also uses the GNU gettext distribution
as a vehicle for documenting its structure and methods. This goes
beyond the strict technicalities of documenting the GNU gettext
proper. By so doing, translators will find in a single place, as
far as possible, all they need to know for properly doing their
translating work. Also, this supplemental documentation might also
help programmers, and even curious users, in understanding how GNU
gettext is related to the remainder of the Translation
Project, and consequently, have a glimpse at the big picture.
Two long words appear all the time when we discuss support of native language in programs, and these words have a precise meaning, worth being explained here, once and for all in this document. The words are internationalization and localization. Many people, tired of writing these long words over and over again, took the habit of writing i18n and l10n instead, quoting the first and last letter of each word, and replacing the run of intermediate letters by a number merely telling how many such letters there are. But in this manual, in the sake of clarity, we will patiently write the names in full, each time...
By internationalization, one refers to the operation by which a
program, or a set of programs turned into a package, is made aware of and
able to support multiple languages. This is a generalization process,
by which the programs are untied from calling only English strings or
other English specific habits, and connected to generic ways of doing
the same, instead. Program developers may use various techniques to
internationalize their programs. Some of these have been standardized.
GNU gettext offers one of these standards. See Programmers.
By localization, one means the operation by which, in a set of programs already internationalized, one gives the program all needed information so that it can adapt itself to handle its input and output in a fashion which is correct for some native language and cultural habits. This is a particularisation process, by which generic methods already implemented in an internationalized program are used in specific ways. The programming environment puts several functions to the programmers disposal which allow this runtime configuration. The formal description of specific set of cultural habits for some country, together with all associated translations targeted to the same native language, is called the locale for this language or country. Users achieve localization of programs by setting proper values to special environment variables, prior to executing those programs, identifying which locale should be used.
In fact, locale message support is only one component of the cultural data that makes up a particular locale. There are a whole host of routines and functions provided to aid programmers in developing internationalized software and which allow them to access the data stored in a particular locale. When someone presently refers to a particular locale, they are obviously referring to the data stored within that particular locale. Similarly, if a programmer is referring to “accessing the locale routines”, they are referring to the complete suite of routines that access all of the locale's information.
One uses the expression Native Language Support, or merely NLS, for speaking of the overall activity or feature encompassing both internationalization and localization, allowing for multi-lingual interactions in a program. In a nutshell, one could say that internationalization is the operation by which further localizations are made possible.
Also, very roughly said, when it comes to multi-lingual messages, internationalization is usually taken care of by programmers, and localization is usually taken care of by translators.
For a totally multi-lingual distribution, there are many things to translate beyond output messages.
gettext offers a complete toolset for
translating messages output by C programs. Perl scripts and shell
scripts will also need to be translated. Even if there are today some hooks
by which this can be done, these hooks are not integrated as well as they
should be.
autoconf or bison, are able
to produce other programs (or scripts). Even if the generating
programs themselves are internationalized, the generated programs they
produce may need internationalization on their own, and this indirect
internationalization could be automated right from the generating
program. In fact, quite usually, generating and generated programs
could be internationalized independently, as the effort needed is
fairly orthogonal.
recode program is able to reconstruct at execution.
Since these descriptions are extracted from the RFC by mechanical means,
translating them properly would require a prior translation of the RFC
itself.
gcc to allow diacriticized characters in identifiers or use
translated keywords; ‘rm -i’ might accept something else than
‘y’ or ‘n’ for replies, etc. Even if the program will
eventually make most of its output in the foreign languages, one has
to decide whether the input syntax, option values, etc., are to be
localized or not.
As we already stressed, translation is only one aspect of locales.
Other internationalization aspects are system services and are handled
in GNU libc. There
are many attributes that are needed to define a country's cultural
conventions. These attributes include beside the country's native
language, the formatting of the date and time, the representation of
numbers, the symbols for currency, etc. These local rules are
termed the country's locale. The locale represents the knowledge
needed to support the country's native attributes.
There are a few major areas which may vary between countries and
hence, define what a locale must describe. The following list helps
putting multi-lingual messages into the proper context of other tasks
related to locales. See the GNU libc manual for details.