DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

(gettext.info.gz) Comparison

Info Catalog (gettext.info.gz) gettext (gettext.info.gz) Programmers (gettext.info.gz) Using libintl
 
 11.3 Comparing the Two Interfaces
 =================================
 
 The following discussion is perhaps a little bit colored.  As said
 above we implemented GNU `gettext' following the Uniforum proposal and
 this surely has its reasons.  But it should show how we came to this
 decision.
 
    First we take a look at the developing process.  When we write an
 application using NLS provided by `gettext' we proceed as always.  Only
 when we come to a string which might be seen by the users and thus has
 to be translated we use `gettext("...")' instead of `"..."'.  At the
 beginning of each source file (or in a central header file) we define
 
      #define gettext(String) (String)
 
    Even this definition can be avoided when the system supports the
 `gettext' function in its C library.  When we compile this code the
 result is the same as if no NLS code is used.  When  you take a look at
 the GNU `gettext' code you will see that we use `_("...")' instead of
 `gettext("...")'.  This reduces the number of additional characters per
 translatable string to _3_ (in words: three).
 
    When now a production version of the program is needed we simply
 replace the definition
 
      #define _(String) (String)
 
 by
 
      #include <libintl.h>
      #define _(String) gettext (String)
 
 Additionally we run the program `xgettext' on all source code file
 which contain translatable strings and that's it: we have a running
 program which does not depend on translations to be available, but which
 can use any that becomes available.
 
    The same procedure can be done for the `gettext_noop' invocations
 ( Special cases).  One usually defines `gettext_noop' as a no-op
 macro.  So you should consider the following code for your project:
 
      #define gettext_noop(String) String
      #define N_(String) gettext_noop (String)
 
    `N_' is a short form similar to `_'.  The `Makefile' in the `po/'
 directory of GNU `gettext' knows by default both of the mentioned short
 forms so you are invited to follow this proposal for your own ease.
 
    Now to `catgets'.  The main problem is the work for the programmer.
 Every time he comes to a translatable string he has to define a number
 (or a symbolic constant) which has also be defined in the message
 catalog file.  He also has to take care for duplicate entries,
 duplicate message IDs etc.  If he wants to have the same quality in the
 message catalog as the GNU `gettext' program provides he also has to
 put the descriptive comments for the strings and the location in all
 source code files in the message catalog.  This is nearly a Mission:
 Impossible.
 
    But there are also some points people might call advantages speaking
 for `catgets'.  If you have a single word in a string and this string
 is used in different contexts it is likely that in one or the other
 language the word has different translations.  Example:
 
      printf ("%s: %d", gettext ("number"), number_of_errors)
 
      printf ("you should see %d %s", number_count,
              number_count == 1 ? gettext ("number") : gettext ("numbers"))
 
    Here we have to translate two times the string `"number"'.  Even if
 you do not speak a language beside English it might be possible to
 recognize that the two words have a different meaning.  In German the
 first appearance has to be translated to `"Anzahl"' and the second to
 `"Zahl"'.
 
    Now you can say that this example is really esoteric.  And you are
 right!  This is exactly how we felt about this problem and decide that
 it does not weight that much.  The solution for the above problem could
 be very easy:
 
      printf ("%s %d", gettext ("number:"), number_of_errors)
 
      printf (number_count == 1 ? gettext ("you should see %d number")
                                : gettext ("you should see %d numbers"),
              number_count)
 
    We believe that we can solve all conflicts with this method.  If it
 is difficult one can also consider changing one of the conflicting
 string a little bit.  But it is not impossible to overcome.
 
    `catgets' allows same original entry to have different translations,
 but `gettext' has another, scalable approach for solving ambiguities of
 this kind:  Ambiguities.
 
Info Catalog (gettext.info.gz) gettext (gettext.info.gz) Programmers (gettext.info.gz) Using libintl
automatically generated byinfo2html