(gettext) Language Implementors
Info Catalog
(gettext) Programming Languages
(gettext) Programming Languages
(gettext) Programmers for other Languages
15.1 The Language Implementor's View
====================================
All programming and scripting languages that have the notion of strings
are eligible to supporting `gettext'. Supporting `gettext' means the
following:
1. You should add to the language a syntax for translatable strings.
In principle, a function call of `gettext' would 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 `_"string"'.
2. You should arrange that evaluation of such a translatable string at
runtime calls the `gettext' function, or performs equivalent
processing.
3. Similarly, you should make the functions `ngettext', `dcgettext',
`dcngettext' available from within the language. These functions
are less often used, but are nevertheless necessary for particular
purposes: `ngettext' for correct plural handling, and `dcgettext'
and `dcngettext' for obeying other locale environment variables
than `LC_MESSAGES', such as `LC_TIME' or `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.
4. You should allow the programmer to designate a message domain,
either by making the `textdomain' function 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 `bindtextdomain' function.
5. You should either perform a `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_MESSAGES' and `LC_CTYPE' locale facets are not both set.
6. A programmer should have a way to extract translatable strings
from a program into a PO file. The GNU `xgettext' program is being
extended to support very different programming languages. Please
contact the GNU `gettext' maintainers to help them doing this. If
the string extractor is best integrated into your language's
parser, GNU `xgettext' can function as a front end to your string
extractor.
7. The language's library should have a string formatting facility
where the arguments of a format string are denoted by a positional
number or a name. This is needed because for some languages and
some messages with more than one substitutable argument, the
translation will need to output the substituted arguments in
different order. c-format Flag.
8. If the language has more than one implementation, and not all of
the implementations use `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.
9. To help the programmer in the task of marking translatable strings,
which is sometimes performed using the Emacs PO mode (
Marking), you are welcome to contact the GNU `gettext'
maintainers, so they can add support for your language to
`po-mode.el'.
On the implementation side, three approaches are possible, with
different effects on portability and copyright:
* You may integrate the GNU `gettext''s `intl/' directory in your
package, as described in Maintainers. This allows you to
have internationalization on all kinds of platforms. Note that
when you then distribute your package, it legally falls under the
GNU General Public License, and the GNU project will be glad about
your contribution to the Free Software pool.
* You may link against GNU `gettext' functions if they are found in
the C library. For example, an autoconf test for `gettext()' and
`ngettext()' will detect this situation. For the moment, this test
will succeed on GNU systems and not on other platforms. No severe
copyright restrictions apply.
* You may emulate or reimplement the GNU `gettext' functionality.
This has the advantage of full portability and no copyright
restrictions, but also the drawback that you have to reimplement
the GNU `gettext' features (such as the `LANGUAGE' environment
variable, the locale aliases database, the automatic charset
conversion, and plural handling).
Info Catalog
(gettext) Programming Languages
(gettext) Programming Languages
(gettext) Programmers for other Languages
automatically generated byinfo2html