Re: tlug: recommendable email software]

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jon" == Jon Babcock <jon@example.com> writes:

    Jon> Bottom line: there IS no system that deals with i18n
    Jon> smoothly, huh?  I guess part of the problem is that not many
    Jon> people want to include multiple scripts in one file, for
    Jon> whatever purpose. Most just want their language plus English,
    Jon> which is an l10n issue. Boohoo.

Not only isn't there one in reality, but nobody's really sketched a
satisfactory one in theory.  But you know that.

>>>>> "Stephen" == Stephen J Turnbull <turnbull@example.com> writes:

    Stephen> Under XEmacs and recent Gnus, Customize is making it a
    Stephen> lot easier.

    Jon> Ok. I've been putting XEmacs aside 'cause I had my brain more
    Jon> than full just dealing with FSF Emacs and 'cause I started
    Jon> with that and 'cause I have a lot of respect for RMS, radical

(FSF) Emacs is a strong competitor, and for true M17N may be somewhat
ahead of XEmacs in principle at the moment.  Quail is not bad.  It's
also not good enough for people who just want one language, but c'est
la vie....

It sticks in my throat, but if you have limited time for dealing with
these questions, you may very well be best off using (FSF) Emacs, at
least for now.  (FSF) Emacs does support the customize interface, so you
should explore that first.  But I get the feeling that Gnus is a more
important component of XEmacs and gets more attention here (the lead
maintainer of XEmacs uses Gnus exclusively for messaging).

XEmacs _may_ shortly (one year from now) start beating the pants off
of That Other Emacs in M17N applications; we're thinking about going
to an internal wchar representation (enormous efficiency gain, 30% on
many individual operations, possibly more on many operations depending
on "random access" to buffer positions) and a better abstraction of
language features (in Mule _all_ language features are embedded in the
character encoding, the proposed model has language properties hung on
extents rather than individual characters).  But it's going to be hell
to implement, and a lot of people think that a better LISP engine
(possibly scheme-based, certainly lexically-scoped) would be a better
use of the effort, so it may not happen soon.

The FSF is not likely to go in that direction at all, sorry to say.
First, if I understood a recent post (in Japanese) to the mule mailing
list correctly, Mule people are aiming at improving the internal Mule
mbchar representation by using UTF-8.  This will have an important
benefit to developers that Unicode can be handled directly without
"kicking out" some existing charsets, and vastly extend the number of
separate character sets that can be handled.  But it's clear that they
intend to use UCS private space and map existing character sets into
it, not use the BMP.  Second, FSF Emacs does not have an efficient
primitive `extent' abstraction on which text properties are hung, the
FSF implementation uses `character properties'.

    Stephen> I18Nizing Mozilla is not going to be that easy; Motif is
    Stephen> not that good at it.  Also, despite the freeing of the
    Stephen> Mozilla code source, the bugs and incompleteness of
    Stephen> Lesstif are going to hold back Linux/FreeBSD interest in
    Stephen> I18N to a great extent IMO.  (Lesstif does not implement
    Stephen> XIM well at all.  If you're satisfied with a read-only
    Stephen> mailer....)

    Jon> Yep. Finding these things out day after day. (Hope you can
    Jon> press Tague on some i18n issues at the meeting and not just
    Jon> Japanese localization problems. Not so subtle hint.)

Tague is a zealot after your own heart.  I was very, very encouraged
by his presentation, and it very much changed my mind about
mozilla/open.  (Not whether it's a good thing; definitely, yes.
Rather, it made me interested in working with them, which I wasn't
much, before.  Purely because Tague is right-thinking on the I18N issue.)

http://www.netscape.com/people/tague is the URL, I think.  The problem 
(as always) is people who don't want to use clunky inefficient
interfaces.  But Tague is even riding the Netscape content providers
to put

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=US-ASCII">

in their HTML <HEAD>s, which is, strictly speaking, completely
redundant.

As I've posted elsewhere, Tague did confirm that gtk will be
supported.  However, the I18N/L10N issue was not clearly drawn out at
the meeting (and Tague said the gtk folks will not give him any
specification as to what and how XIM and other I18N issues are going
to be handled under gtk).  I did see a demonstration of Japanese input
and output under gtk at the meeting, so it does work.  How soon it
will be robust enough for mozilla/open is as yet an open problem.

I'm not sure I like the approach that Netscape has adopted according
to Tague.  In particular, Netscape, like Mule, embeds a lot of locale
information in the character encoding.  I don't want to have to learn
Chinese I/O to be able to search for "汽車" in a Chinese page....  I'd
like to be able to search at Yahoo on the regexp "[汽電]車" to pull up
_both_ Japanese and Chinese pages on trains....

Still, he's a talk-to-able guy.  Check out his page.  If you write to
him with a subject including "TLUG", he says he'll give it priority :-)

HTH

---------------------------------------------------------------
Next TLUG Meeting: 11 April Sat, Tokyo Station Yaesu gate 12:30
Featuring Tague Griffith of Netscape i18n talking on source code
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096