Thankfully, nearly all of this horridity you bring up is irrelevant. In
XEmacs, "gettext" does not refer to any standard API, but is merely a stand-in
for a translation routine (presumably written by us). We may as well call it
something else. We define our own concept of "current language". We also
allow for a function that needs a different version for each language, which
handles all cases where simple translation isn't sufficient, e.g. when you
have to pluralize some noun given to you or insert the correct form of the
definite article. No weird hacks needed. No interaction problems with other
pieces of software.
What I wrote "awhile ago" is (unfortunately) not anywhere public currently,
but it's on my list to put it on the web site. "There you go again" is
usually not true; most of what I quote was indeed put out publicly at some
point, but I'll try to be more explicit about this in the future.
"Stephen J. Turnbull" wrote:
>>>>> "Ben" == Ben Wing <ben(a)666.com>
Ben> "Stephen J. Turnbull" wrote:
>> What I have in mind is not just gettext-izing everything in the
>> XEmacs core sources. I currently believe that to be
Ben> I don't quite understand. Could you elaborate and give some
First, there's the surface of Jan's y-or-n-p example. You have to
coordinate the translation of the message string and the response
prompt. This is handled by y-or-n-p itself (I see that we already do
have gettext for Emacs Lisp, that's nice to know).
Except that it's not really handled by y-or-n-p. There's no reason to
suppose that somebody writing a Lisp package would necessarily use the
XEmacs domain (in fact, due to the way gettext binds text domains---if
I understand that correctly---we don't want that to be the case,
because it means that every time a Lisp package is updated the whole
XEmacs catalog must also be updated). So which domain gets used for
the message string?
In the current implementation, it is the domain of y-or-n-p. So
packages with their own domain won't get y-or-n-p prompts correctly
translated. But that means that the package should do its own
translation. But now you're applying gettext to the same string
twice; you just have to pray the that translator upstream doesn't
collide with an English string that's in the XEmacs domain. (The
gettext docs mention the similar problem of English words with
multiple meanings that must map to different words in the target
language; this can be disambiguated by various trickeries in forming
the strings ... but only if you "own" them, which in the multi-domain,
interated gettext example you do not.) AFAICT this means that you
must never pass untranslated strings across public APIs, but this may
or may not be reasonable, and certainly is inconvenient.
Next, we have to translate the possible answer strings to match the
language being passed by the user. This is presumably OK here,
because it's done by y-or-n-p. But what if y-or-n-p returned a string
rather than a boolean? Then we would need to coordinate the
presentation of the prompt (done by y-or-n-p) and the translation of
the possible answer strings (done by the caller). This can in fact be
done using dgettext with the XEmacs domain, but you must know that
y-or-n-p is in the XEmacs domain. This is not necessarily going to be
obvious, and it might very well be that sets of related packages might
have the same domain, so you wouldn't necessarily know which domain is
appropriate by looking at the requires.
And what happens if one domain does supply translations for a language
and the other does not? AFAIK, gettext has no way to find out if this
is the case. But you might very will prefer a global fallback to
English if substantial phrases are drawn from both domains, while you
might prefer string-by-string fallback if the main text is translated
and only a few words are left to fallback to English.
Aside from confusing users, this puts a great burden on programmers.
Programmers need to know about the status of the domains of packages
they use as well as the XEmacs domain; they need to program
defensively against the possibility that some package they use will
become gettext-ized, or the translation projects will be out of synch
(some teams will do the calling package first, others will do the
caller package first).
I don't think anybody will use gettext in these circumstances. At
least not after they get the first bug report that "XEmacs is stuck in
an infinite y-or-n-p loop and I can't get out."
Ben> I wrote this awhile ago:
"There you go again." Not anywhere I could see it! (At least, it
doesn't look familiar and grepping the archives doesn't turn it up.)
OK, you win. Subscribe me to xemacs-review. Or whatever seems
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be patient.
If you need an immediate response and it is not apparent in your message,
please say so. Thanks for your understanding.