(gettext.info)Language Implementors

---

Next: Programmers for other Languages Prev: Programming Languages Up: Programming Languages

---

Enter node , (file) or (file)node

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-related 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 categories 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.  Note: 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 (Note:
     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 Note: 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).