[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gettext-based localization
Perhaps others have had different (and better) experiences with gettext and
including message strings throughout the code.
I'm not a gettext expert (so I'm probably the wrong person to be
arguing this), but I'm not sure we're talking about the same thing.
When using gettext, the (human) translator don't normally look at
the code. Instead, a tool scan the code, looking for calls to gettext,
and generates a list of messages to translate. A translator can then
systematically go through the list, translating each message.
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.
> 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.
> The need for package is in this context is--to me- exactly the same as
> the need for packages in Java. With large numbers of developers
> working on development of the same system, namespace control is a
No disagreement there. I'm just suggesting that instead of requiring
programs to make up and manage message ids, we just use the actual
message in the primary langauge as its own id/tag. The translation
is still specific to some named package.
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