Re: [Fwd: tlug: vine]

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

>>>>> "Scott" == Scott Stone <ss8913@example.com> writes:

    Scott> "HY" == Hirotaka Yoshioka wrote:

    HY> I am a programer who has experience more than 15 years to do
    HY> some software localization (Japanization/Asianzation) and
    HY> internationalization.

Oh boy, somebody who's actually been at this for a while.  You're in
my BBDB, you can't escape now!  Where were you when I needed somebody
to dump that Linux Journal article on?  :-)

    Scott> THIS I must see.  Having pulled my hair out many a time at
    Scott> PHT over, "The japanese patch to (package) has rendered it
    Scott> completely useless for anyone ELSE besides the Japanese"

And why shouldn't it?  Obviously (based on past posting and
publications), I consider I18N to be only a halfway house to the Only
True Way of M17N.  But that's a lot of work to do to get the results
you need if you have to reverse-engineer somebody else's work.

What's important about I18N and M17N is that not only do they
facilitate cross-locale generalization, they also facilitate cross-
version generalization (so that you don't have to redo a patch every
time the upstream developers bump the version).  That these go hand-
in-hand is a very attractive bonus, of course.

    Scott> (example: pine-jp converts European accent marks/etc into
    Scott> kanji)

Pine's fault, it can only handle two MIME charsets at a time in a
message body, and one of them must be ASCII.  Heck, even Wile Y. C
gave up on that one.  Yes, you could do a better job of guessing than
the current patch does, but it's not necessarily worth trying when
EUC-JP isn't sufficiently polite to say "shitsurei shimasu" before
entering a message---there's an inherent ambiguity in ISO-8859
vs. EUC-JP, and unfortunately there are still a lot of legacy mailers
(on Unix) and outright intentional sabotage (eg, Outhouse Excess) that
lie in their MIME headers, so relying on MIME is not a good way to
make users happy.

    Scott> and the ever-popular "Ulrich doesn't give a rat's a** about

Not true.  But he's not willing to break his head over SJIS, EUC-JP,
and JIS all at the same time.  He cares, just not very much.  And not
at all if it's not going to work correctly and simultaneously with
Chinese and UCS.

    Scott> Japanese and rightly so since the Japanese glibc patch is,
    Scott> well, a pile of rat sh**" problem... apparently there's some
    Scott> compatibility issues with glibc 2.1 vs nihongo, but I haven't
    Scott> delved into the details of that one yet (no longer my
    Scott> problem, thankfully).

    HY> I think the issues on Japanese patch are
    HY> 1) The code itself is not so good.

That doesn't stop non-Japanese patches from getting in ;-)

    HY> 2) The programer which made the patch is not experienced with
    HY> the internationalization

So somebody should educate them (preferably Uli, but he's busy, I'm sure).

    HY> 3) He/she does not care the importance of the merge into
    HY> the baseline. He/she does not understand well the importance.

This I don't understand.  Isn't the importance obvious?  Why don't
Japanese programmers care about merging?  In fact they do; in the
Emacs context Japanese programmers are perhaps more upset about the
XEmacs/FSF split than others, and are quite active in producing
workarounds and emulations.  But for some reason this does not extend
to fixing their own code to work correctly in situations they
personally don't care about, even when it would mean they could put
the maintenance burden on someone else.

With the spectacular exceptions of X11 and Mule, of course.  But it's
really unfortunate to see slick tools like Magicpoint, VFlib, and
xfs-tt get ignored by the rest of the world because of one or another
fault of communication.  And see the same patches get rereleased time
and again for new versions of the upstream software.

And even with Mule, except for the official stuff being directed by
Handa-san, efforts to make Japanese contributions palatable to the
rest of the world are pretty hit and miss.  To the point where some of 
the XEmacs maintainers once threatend a Naggum-like "Mule survival
kit."

If Japanese programmers don't care about merging, that's tough for the 
rest of us.  But I would like to understand why not :-(

    Scott> So the Debian folks have a choice to make - go to glibc 2.1
    Scott> and possibly break Japanese, or stay with 2.0 longer and
    Scott> lag a bit behind the rest of everyone.  I think that TL is
    Scott> experiencing a similar issue.

Well, I hope they break the Japanese so that it will get fixed right.

Anyway, Ulrich was promising a correct fix for the wctombs stuff at
end of March, maybe it will happen for 2.2 ;-)

-- 
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 two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Technical Meeting: June 19 (Sat), 18:30  place: Temple Univ.
*** Topics: 1. Linux SMP on a quad-Xeon server
2. The Green Frog Linux distribution
Next Nomikai: July 16 (Fri), 19:30 Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan