9:22 a.m.
"Stephen J. Turnbull" wrote:
>>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
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.
I don't quite understand. Could you elaborate and give some examples?
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
_potential_ users.
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
past.
I wrote this awhile ago:
--------------------------------------- cut
------------------------------------
Here is a more detailed list of Mule-related projects that we will be
working on. They are more or less ordered according to how we will
proceed, but it's not exact. In particular, there will probably be
time overlap among adjacent projects.
1. Modify the internal/external conversion macros to allow for
MS Windows support.
2. Modify the buffer macros to allow for more than one internal
representation, e.g. fixed width and variable width.
3. Review the existing Mule code, especially the lisp code, for code
quality issues and improve the cleanliness of it. Also work on
creating a specification for the Mule API.
4. Write some more automated mule tests.
5. Integrate Tomohiko's UTF-2000 code, fixing it up so that nothing is
broken when the UTF-2000 configure option is not enabled.
6. Fix up the MS Windows code to be Mule-correct, so that you can
compile with Mule support under MS windows and have a working
XEmacs, at least just with Latin-1.
7. Implement a scheme to guarantee no corruption of files, even with
an incorrect coding system - in particular, guarantee no corruption
of binary files.
8. Make the text property support in XEmacs robust with respect to
string and text operations, so that the `no corruption' support in
the previous entry works properly, even if a lot of cutting and
pasting is done.
9. Improve the handling of auto-detection so that, when there is any
possibility at all of mistake, the user is informed of the detected
encoding and given the choice of choosing other possibilities.
10. Improve the support for different language environments in XEmacs,
for example, the priority of coding systems used in auto-detection
should properly reflect the language environment. This probably
necessitates rethinking the current `coding system priority'
scheme.
11. Do quality work to improve the existing UTF-2000 implementation.
12. Implement preliminary support for 8-bit fixed width
representation. First, we will only implement 7-bit support, and
will fall back to variable width as soon as any non-ASCII
character is encountered. Then we will improve the support to
handle an arbitrary character set in the upper half of the 8-bit space.
13. Investigate any remaining hurdles to making --with-mule be the
default configure option.
--------------------------------------- cut
------------------------------------
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
fonts model.)
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.
If you'll implement it, I'll design it. It's more a case of will on your
part
than anything else. I can give you instructions sufficient enough to match
your level of expertise.
ben
--
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.