Subject: Re: (i18n 46) Re: Japanese Profile

From: Erik M. van der Poel <[email-masked]>
Date: Thu, 13 Dec 90 21:38:50 +0900

> > The interpretation of ellipsis (...) depends on underlying encoding.
> > For example my definition will work for encoding so-called 7-bit-
> > JIS (which are used in JUNET) as well as UJIS, but will not on
> > Shift-JIS nor Kanji codes which are not based on JIS X0208.
> > 
> > Sekiguchi
> 
> I don't think it is a question of whether or not it will "work". If
> the system is implemented properly, it should collate even Shift-JIS
> exactly as you specify in your ellipsis definitions. Of course, it
> cannot be as efficient as JIS, since there is no one-to-one
> relationship between the collation definition and the Shift-JIS code.
> 
> Erik

Oops, I just realized that I made a mistake. The character ranges in
LC_COLLATE are *not* based on the symbolic names in the ranges, they
are based on the encodings of the characters.

I was thinking of the *charmap* proposal, where the ranges *are* based
on the names, e.g.:

	<j1601>...<j1694>

Now I'm beginning to wonder about the LC_COLLATE specs. The charmap
concept was introduced in order to be able to free the locale
definitions of any encoding dependencies. Yet, the LC_COLLATE ellipsis
specs are explicitly encoding dependent. Isn't this rather
inconsistent?

Erik