tlug: Introduction; Looking for Help on i18n

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

>>>>> "Kai" == Kai Wetzel <k.wetzel@example.com> writes:

    Kai> There are some things which we have very little knowledge of
    Kai> and it would be cool if you people could help out, here:

    Kai> - Programming support for i18n within X11 (Xlib) as well as
    Kai> C++(and C).  (Since this is what the LIP uses primarily)

All versions I have used of XIM for X11R6 are buggy.  X11R6.1 is very
hosed on Sparc/Linux to my personal knowledge.  It is reputed to be
very bad on i386/XFree86 as well, but this I don't know from personal
experience.  XFree86 3.3's bugs (that I know of) can be worked around
(although I haven't tried this with glibc yet).

C/C++?  Support?  NOT.  There is some support for POSIX locales in
Linux glibc, but no documentation I can find (I haven't looked that
hard, and have not joined the ML, though) and no database for
Japanese.  Message catalogs are essentially nonexistent (although
there's one for sharutils for Japanese, Heaven only knows why).
Unicode support is extremely sketchy, and it's not clear to me how bad
it will bomb (maybe it will fail gracefully...) if you feed say
Japanese to it.  My main machine is still libc5 so I don't know what's
up here.

Lesstif still has problems in general.  I don't know about its I18N
aspects (eg, XmIm...() functions).  Mo'tif is of course proprietary.

    Kai> - Programming for i18n using Windows NT, Macintosh, and Java
    Kai> (JDK 1.1).

JDK seems to do pretty well, but is not ready for prime time.  Out of
the box the properties.ja expects you to have Sun fonts and the
interpreter proceeds to dump core if you don't have them.  Edit
properties.ja so that it references available fonts and you're OK.
The stream filters work in toy applications (CGI/servlets).  Maybe....
It's too damn slow to be worth my time to figure out what's going on.

    Kai> - Issues involved in programming for i18n in general.

    Kai> - Standards in this area, including UNICODE, etc.

Sell your car, buy the book.  Unfortunately the folks at ISO and
Unicode want to make money from their standards, enough that they
won't give away the standards so that there's a prayer that the
standards will get implemented.

    Kai> We will need people who would like to discuss the design of
    Kai> i18n classes and integrating them with our existing classes,

i18n _classes_?  You've already missed the boat....  If the
functionality isn't embedded deep within the classes you already have,
nobody is going to bother to retrofit.  Look at the Java API (java.io,
I think) for hints; I don't like it very much (probably from lack of
use), but you'll see that the i18n features are implemented as filter
methods on the base classes.  Right way to go, IMHO.  Unless you plan
to implement multiple inheritance and have the i18n classes override
the base ASCII or Latin-1 implementation.  But that's pretty
error-prone.

    Kai> as well as people who would possibly like to help implement
    Kai> this design when it's done.

Ah ... no, I don't think so; I've got a couple of other projects on
the fire.  I'll take a look at the web page one of these days, though.
Maybe I'll change my mind.

Regards,
Steve

-- 
Yaseppochi-Gumi

REAL solutions to the REAL problems of REAL people in REAL time.  REALLY.
Like, NOT!
Next TLUG meeting is Saturday Dec. 13, 1997  (possibly Nov. 13?)
---------------------------------------------------------------
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