Re: tlug: Introduction; Looking for Help on i18n

[Kai Wetzel <k.wetzel@example.com>]

Stephen J. Turnbull wrote:
> 
> (By the way, it's not clear to me whether you are subscribed to the
> list; if you're getting two copies and it's annoying you, say so and
> I'll stop sending to both.)

Yes, I'm subscribed.

> >>>>> "Kai" == Kai Wetzel <k.wetzel@example.com> writes:
> 
>     Kai> The LIP has to determine what we can provide in the library
>     Kai> and what would be out of scope or is beeing worked on by
>     Kai> other people.  I can't say much about this myself, since I
>     Kai> only know that my Linux/X11 has vertially no support for
>     Kai> anything outside of the "C" locale :(
> 
> This I can help with.  X11 intends to use the system's native locale
> support, and by default locale support is provided by libc. 
[...]
> This substitutes X11's functions for libc's.  The database is in
> /usr/X11R6/lib/X11/{i18n,locale,nls} some or all of which are symbolic
> links to each other.  This database is not compatible with the POSIX
> format.  If you don't have that database, you're in trouble, of course.

Hmm, I'll have to check.

[...]
>     Kai> Well, there is e.g. the class "locale" and there seems to be
>     Kai> some other facilities.  I don't know how complete they are
>     Kai> and I don't know how much of them is usable in common
>     Kai> implementations of the standard C++ library.
> 
> Right, but without the database they're nothing.  Some of the locale
> data are shit^H^H^H^Halpha (I believe this is true for Korean);
> without docs, you can't tell which are good.  And some locales have
> simply gone missing and nothing is said about attempts to put them
> together (eg, Japanese).

I see.  The Free Software Union will start it's Special
Interest Group on i18n soon, and I hope it could at least
bring some light into the "who's doing what where" question.

[...]
> I may be wrong, but I suspect that if you look closely you will see
> that some or all of these classes are actually integrated into very
> low levels of the API.  Of course you _need_ a locale class to manage
> the various aspects of locale (for example, a Frenchman reading mail
> from the US might very well want the currency symbol to be `$' but the
> decimal separator to be `,', so custom locales will be necessary for
> some cranky users).  But the fact that it's user-visible doesn't mean
> that it doesn't go all the way to the root of the IO classes.

Yes, this could affect the core LIP classes significantly.
Since we don't provide much in some areas such as input
handling, it may not be too bad.

> Again,
> I think you have it backwards about fonts; the fonts actually come
> last in the display pipeline:

Yes, the problem with fonts is that we do it somehow
already, so this area actually has to change significantly
while the one or two calls to XLookup.. wouldn't be missed
very much ;)

>    markup -> format dates, etc -> line-breaking by font metrics ->
>                          display using fonts
> 
> and so can be grafted on at the last second.

A little problem which may arise with font handling in general is
that X doesn't provide all needed features, but I don't know about
the implications of this, yet.

kai

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