At Wed, 10 Sep 2003 13:53:20 +0200, Vincent Lefevre wrote: > On 2003-09-10 11:17:25 +0100, Colin Watson wrote: > > On Wed, Sep 10, 2003 at 12:10:25PM +0200, Vincent Lefevre wrote: > > > I agree, but then, why not accept "ISO-8859-1" only, from the user's > > > point of view? > > > > You might as well just leave it at C. It doesn't provide the case > > conversion functions (say) with any extra information. > > But then, I would no longer be able to use accented characters. > > > More to the point, it's not implemented, not required to be implemented, > > and not necessary for localization. :) > > Being able to choose "ISO-8859-1" without giving the language could be > useful to use a single value on multiple machines, as not all locales > are installed (and not anyone is root to generate the missing locales).
In first, I don't think only setting "ISO-8859-1" is valid. Because we can't distinguish it's language name or codeset. But as you wrote, if we use ".ISO-8859-1", we can easily understand it's coding name. However POSIX has no capability to deal with this form; "XX" or "XX_YY" or "XX_YY.ZZ" or "[EMAIL PROTECTED]" are designated as valid locale name (XX and YY have to be ISO language/country name. POSIX does not refer to apply this rule for ZZ and UU). And POSIX also define that the locale name should regress from right to left; so XX_YY.ZZ -> XX_YY -> XX is ok, but only setting ZZ is not valid. So, only designating ".ISO-8859-1" is not valid. However, AFAIK you may be enable to use "C.ISO-8859-1" (I have not tested yet). BTW, you should understand LC_CTYPE is special locale category: other LC_* rules depend on LC_CTYPE character set. So playing with just LC_CTYPE is not practical. If you think it's limit, yes you're sane. The current POSIX locale scheme has limitation for handling with LC_CTYPE. But in another word, the current POSIX locale scheme is realistic; we can implement easier than more difficult language handling scheme. If you read locale specification, and you find good way to handle localization/internationalization/multilingualization compared with the current locale framework, please implement and standardized it (I understand the current POSIX locale have less flexible for multilingualization without unified codeset like Unicode). Conclusion: I reject your proposal because it is not valid for POSIX locale scheme. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
