Make wine honor LC_CTYPE and LC_MESSAGES

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>"Shachar Shemesh" <wine-patches at shemesh.biz> wrote:
>
>  
>
>>Following a discussion with Alexandre on IRC, here is a revised patch. 
>>This one doesn't touch the LC_MESSAGE, as these do not affect the user 
>>locale. Further work will be necessary on supporting MUI like language 
>>checking.
>>    
>>
>
>  
>
>>     if ((lang = getenv( "LC_ALL" )) ||
>>-        (lang = getenv( "LANGUAGE" )) ||
>>+        (env1 && (lang = getenv( env1 ))) ||
>>         (lang = getenv( "LANG" )))
>>    
>>
>
>I think that re-introducing an ability to change Wine's locale
>with LC_CTYPE is flawed.
>
That's not what I'm trying to do.

> Remeber, that current ANSI code page
>affects not only keyboard input, but also all things depending
>on MultiByteToWideChar/WideCharToMultiByte conversions, that's
>all resource strings and hardcoded non-unicode application strings.
>  
>
Good. That's the effect I'm trying to achieve here. LC_CTYPE controls 
what codepage the system is in. Wine should inherit that.

>If you are trying to fix keyboard input, you have to fix it not
>in Wine, but in your Linux locale setup. If you have LC_ALL, LANG
>and LC_TYPE pointing to different locales your setup is broken.
>  
>
If I have LC_ALL pointing to something, then that's what everything is. 
LANG, on the other hand, is defined to the lowest precedence there is, 
AFTER LC_*.

If I have LC_CTYPE and LANG pointing at different things, it may be 
because I want to speak one language, but have an encoding that belongs 
to another. There is nothing broken with that, and there is no reason 
not to support that.

             Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/