[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext-based localization

This page is part of the web mail archives of SRFI 29 from before July 7th, 2015. The new archives for SRFI 29 contain all messages, not just those from before July 7th, 2015.

In a message dated 4/12/2002 3:43:11 PM Central Daylight Time, 
per@xxxxxxxxxxx writes:

>  compatible with it.  I suggest at least a quick look at the gettext
>  manual: http://www.gnu.org/manual/gettext/html_chapter/gettext_toc.html

I admit I am not a gettext expert, AT ALL. I will take a look a closer look 
at it.

>  What I don't understand is how using a message tag (or a
>  message number) to identify a message instead of using the
>  message itself (in some primary language) as the tag helps with
>  any of the issues you mention.  You're just adding an extra
>  level of indirection, and while that is sometimes useful, here
>  you're just adding extra cognitive overhead managing the tags.

From the descriptions of a gettext mechanism you have provided, I would have 
calls like the following throughout my code:
   (getttext "(Critical): Link congestion"))

And you say that there are tools that would pull together this information 
into a single file for translators and documentors, ok.

But if I were using this mechanism, I would (and would insist that the whole 
project did so) define all these strings in a central module(s), on the order 
   (module AlarmTags mzscheme
        (define LinkCong "(Critical): Link Congestion")
        (provide (all-defined))

From one perspective, this might even be better than using message tags: at 
least the compiler could complain when the identifiers are not bound.

But I wonder how gettext-style tools would handle this?

>   > But it also makes the process of writing customer documentation (both
>   > in the primary language and the various "foreign languages") easier
>   > when all such messages are in a single place.
>  In the gettext model, they are.  Each package has a .pot and one .po
>  file for each supported language.  These are generated from the sources,
>  using a utility program.

I should have been more clear: with the message-tags, the message texts would 
ONLY be in a single central place. Consistency between code, the translators 
and the customer documentation is a nightmare by any mechanism, as far as I 
am concerned. To have the tags spread throughout the code as well as these 
.pot files is just an added risk.

>  Let's not re-invent the wheel.  There is a standard used by lots of Free
>  Software.  It works.  A message translation SRFI really needs to be
>  compatible with it.  I suggest at least a quick look at the gettext
>  manual: http://www.gnu.org/manual/gettext/html_chapter/gettext_toc.html

Another data point for a well established mechanism is the Java API for 
internationalization (http://java.sun.com/products/jdk/1.1/docs/guide/intl/). 
They use strings instead of the more elegant symbols of Scheme/Lisp, but they 
seem to come down on the side of message tags. The code has references to 
strings that are resource names, where resource bundles provide the 
English/French/whatever text of the message.

By the way, I don't per se disagree with having a SRFI that could be 
implemented via gettext, but wouldn't implementing localization in Kawa be 
easier via Java's internationalization mechanisms?

Jim Bender