In a message dated 4/12/2002 3:43:11 PM Central Daylight Time,
xxxxxx@bothner.com 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
of
   (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