GNU Info

(gettext.info)Comparison

---

Next: Using libintl.a Prev: gettext Up: Programmers

---

Enter node , (file) or (file)node

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
(Note: 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: Note: Ambiguities.