DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(gettext.info.gz) Language Implementors

Info Catalog (gettext.info.gz) Programming Languages (gettext.info.gz) Programming Languages (gettext.info.gz) 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.info.gz) Programming Languages (gettext.info.gz) Programming Languages (gettext.info.gz) Programmers for other Languages
automatically generated byinfo2html