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 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