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