>>>> "Ben" == Ben Wing <ben(a)666.com>
Ben> Implementing message translation is not that hard.
What I have in mind is not just gettext-izing everything in the XEmacs
core sources. I currently believe that to be unacceptable (see Jan's
message for the pitfalls in I18N; it's worse for M17N). I think
really solving this problem needs a specifier-like fallback mechanism
(this would solve Jan's example because you could query the
text-specifier presenting the question for the affirmative and
negative responses, and the catalog-building mechanism would have
checks to make sure they were properly set, perhaps a locale
(language) argument), and gettext is just not sufficient for that.
At a minimum, we need to implement gettext for Lisp packages.
(Currently, gettext is only implemented for C AFAIK.) But this could
potentially cuase more trouble than it's worth.
Ben> A lot depends on priority: How important do you think this
Ben> issue is to your average Japanese/Chinese/etc. user?
Which average Japanese (etc) user? The English-skilled (relatively)
programmer in the free software movement, or my not-at-all-competent
undergrad students who I would love to have using an Emacs? This is a
really important ease-of-use issue.
Realistically, for Japanese, it's low priority. The Japanese team in
the GNU Translation Project is doing very little AFAIK, so even if the
capability were there, I doubt the message catalog would soon be done.
But I think that many non-English speakers would find it very
attractive, and for many languages there are well-organized and
productive translation teams. I suspect that if the I18N facility
were well-designed, many Western European languages would have full
catalogs within a year (granted, they are the ones where it's least
needed :-( ).
Personally, I think doing it well is hard, and of little benefit to
_current_ core XEmacs constituency. I think doing a good job, with
catalogs, would be very attractive to many non-English-speaking
Ben> How does it compare to some of the other important Mule
Ben> issues that Martin and I are (trying to work) on?
I don't know what you guys are _trying_ to work on. Everything in the
I18N section of "Architecting XEmacs" is red-flagged. OTOH, it's
clear from your posts that you are overburdened, so I can't read
priority into the fact that you've responded to specific issues in the
What I see as Mule priorities (in rough benefit order, I am not taking
account of difficulty, nor the fact that some - eg 8 & 10 - will
probably come as packages):
1. Fix the autodetect problem (by making the coding priority list
user-configurable, as short as he likes, even null, with "binary"
as the default).
2. Document the language environments and other Mule "APIs" as
implemented (since there is no real design spec). Check to see
how and where they are broken.
3. Make the Mule menu useful to non-ISO-2022-literate folks.
4. Redo the lstreams stuff to make it easy and robust to "pipeline",
eg, libz | gnupg | jis2mule.
5. Make Custom Mule-aware. (This probably depends on a sensible
6. Implement the "literal byte stream" memory feature.
7. Study the FSF implementation of Mule for background for 7 & 8.
8. Identify desirable Mule features (eg, i18n-ized messages as above,
collating tables by language environment, etc). (New features
might have priority as high as 9.)
9. Specify Mule UIs, APIs, etc, and design and (re)implement them.
10. Implement the 8-bit-wide buffer optimization.
11. Move the internal encoding to UTF-32 (subject to Olivier's caveats
regarding compose characters), with the variable-width char
buffers using UTF-8.
12. Implement the 16- and 32-bit-wide buffer optimizations.
There's surely other stuff I've forgotten.
Ben> The big question is, would you be willing to help do the
Ben> actual implementation, to "be my hands"?
Sure, subject to the usual caveat that I'd need to be convinced it's
worth doing and a secondary caveat that I am not an experienced coder.
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."