🚀 go-pugleaf

Sender: sander.cupertino.ca.us!paul@sander.cupertino.ca.us (Paul Sander)

Karl Heinz Kremer writes:

>Glenn Wright (Glenn.Wright@UK.Sun.COM) wrote:
>> And finally, one sample implementation of the gettext()
>> interface is available in the public domain. You could include this in
>> applications for systems that do not supply gettext(). See:
>>
>>        ftp.uu.net:/archive/systems/sun/gettext-messaging.tar.Z

>BUT: You need at least one additional file to use this version
>of gettext. The file libintl.h is not part of the tar file.

>Do you have any idea where i can get this file?

This should be sufficient to get it working:

#ifndef TEXTDOMAINMAX
#define TEXTDOMAINMAX 256
#endif

#ifdef __STDC__
extern char *dgettext(const char *, const char *);
extern char *gettext(const char *);
extern char *textdomain(const char *);
extern char *bindtextdomain(const char *, const char *);
#else
extern char *dgettext();
extern char *gettext();
extern char *textdomain();
extern char *bindtextdomain();
#endif

I'm curious about how popular these interfaces are for internationalization
and localization, for I find its capabilities are insufficient, even for its
limited scope (which is to select a message for a specific locale given a
domain and ID number, and return a pointer to the text).

My biggest complaint is that messages cannot be longer than one line, at
least not with this implementation.  I almost never write messages that
short.  My messages also often require additional data (which is computed
at runtime, e.g. a path read from a profile file, a file name entered
by the user, and the error message picked up from sys_errlist) to be
inserted into the message read from the message file.  I usually perform
token replacement in a way that allows me to reorder the computed data to
suit the grammar of the target language.  Although there is nothing stopping
me from performing the token substitution, the short length of the messages
requires me to split up long messages with lots of computed data into short
messages with at most one computed item.

My other big complaint is that, short of hacking the source for gettext
and making it non-standard, it is impossible to replace the default messages
with the ones in the message files while the current locale is the "C"
locale.  This, in combination with other things, makes it impossible for
me to evaluate the contents of my message files by executing the applications
for which they are intended.  A new locale must be installed on my machine
since the "C" locale is the only one available to me.  And installing new
locales appears to be reserved to the vendor.  I'm using a Sun system, so I
assume that mine is not an unusual situation (given Sun's perceived relative
openness and relatively good support).

Other than these problems, the gettext library seems to be fine for very short
messages.  I'll probably use it for small, simple programs that don't have much
output.

Paul Sander