Re: bad side-effects of new locale design

[Stanislav Meduna <stano at trillian dot eunet dot sk>]

Hello,

> > Examples (I have strace without locale support):
> > LANG=C LANGUAGE=czech strace /
> > execve("/", ["/"], [/* 47 vars */])     = 0
> > strace: exec: P??stup odm?tnut
> 
> That's no nad design.  The program just does what you told it to.  The
> C locale uses ASCII as the charset.  I can show you environments
> (e.g., mine) where the old behavior led to problems.

For example? I do trust you :-) but I'm really curious.

> > Case 1 can be very painfull and needs fix.
> 
> The program has to be fixed.

You are right that the program is broken and glibc is allowed
to do what it does. Unfortunately, there is a ton of programs
that don't bother to call setlocale, but the user wants to see
localized messages at least from the glibc. The users
_will_ be confused by this incompatibility and the problem
will have no end in sight. 

I know this from the X side of story - if a program don't
call some specific functions, there won't be dead key
support without very ugly hacks (I wrote one of them :-)).
The problem is known for years and still the developers
simple ignore it - if it works for english, it's enough.

If there is any possibility for the old behaviour
(even as non-default setting or some workaround),
I would like to see it there.

If you want to be strict conform, maybe it would
be better to be even more radical - don't allow message
catalogs in non-ascii charset in an ascii locale.

Regards
-- 
				Stano