Copyright (C) 2000-2012 |
GNU Info (gettext.info)ComparisonComparing 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. automatically generated by info2www version 1.2.2.9 |