Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work
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 "XX_YY.ZZ@UU" 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
Reply to: