All programming and scripting languages that have the notion of strings
are eligible to supporting
means the following:
gettextwould do, but a shorthand syntax helps keeping the legibility of internationalized programs. For example, in C we use the syntax
_("string"), and in GNU awk we use the shorthand
gettextfunction, or performs equivalent processing.
dcngettextavailable from within the language. These functions are less often used, but are nevertheless necessary for particular purposes:
ngettextfor correct plural handling, and
dcngettextfor obeying other locale-related environment variables than
LC_MESSAGES, such as
LC_MONETARY. For these latter functions, you need to make the
LC_*constants, available in the C header
<locale.h>, referenceable from within the language, usually either as enumeration values or as strings.
textdomainfunction available from within the language, or by introducing a magic variable called
TEXTDOMAIN. Similarly, you should allow the programmer to designate where to search for message catalogs, by providing access to the
bindtextdomainfunction or — on native Windows platforms — to the
setlocale (LC_ALL, "")call during the startup of your language runtime, or allow the programmer to do so. Remember that gettext will act as a no-op if the
LC_CTYPElocale categories are not both set.
xgettextprogram is being extended to support very different programming languages. Please contact the GNU
gettextmaintainers to help them doing this. The GNU
gettextmaintainers will need from you a formal description of the lexical structure of source files. It should answer the questions:
Based on this description, the GNU
can add support to
If the string extractor is best integrated into your language’s parser,
xgettext can function as a front end to your string extractor.
gettextmanual will be extended to include a pointer to this documentation.
Based on this, the GNU
gettext maintainers can add a format string
equivalence checker to
msgfmt, so that translators get told
immediately when they have made a mistake during the translation of a
gettext, but the programs should be portable across implementations, you should provide a no-i18n emulation, that makes the other implementations accept programs written for yours, without actually translating the strings.
gettextmaintainers, so they can add support for your language to po-mode.el.
On the implementation side, two approaches are possible, with different effects on portability and copyright:
gettextfunctions if they are found in the C library. For example, an autoconf test for
ngettext()will detect this situation. For the moment, this test will succeed on GNU systems and on Solaris 11 platforms. No severe copyright restrictions apply, except if you want to distribute statically linked binaries.
gettextfunctionality. This has the advantage of full portability and no copyright restrictions, but also the drawback that you have to reimplement the GNU
gettextfeatures (such as the
LANGUAGEenvironment variable, the locale aliases database, the automatic charset conversion, and plural handling).