Make wine honor LC_CTYPE and LC_MESSAGES

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>"Shachar Shemesh" <wine-devel at shemesh.biz> wrote:
>
>  
>
>>>I explained it many times already: because you can't have different locales
>>>for keyboard input, string collation and to/from unicode conversion routines.
>>>
>>> 
>>>
>>>      
>>>
>>Ok, it seems that we are walking around in circles here.
>>
>>Windows has it. Just set system locale to one thing (code page, to/from 
>>unicode), and user locale to something else (collation).
>>Unix has it (LC_COLLATION and LC_CTYPE).
>>Why shouldn't wine?
>>    
>>
>
>I still didn't hear from you from you are calling user locale in Windows,
>that's the source of misunderstanding I guess.
>  
>
User locale determines collation and default date, time and monetary 
formats. More precisely, it determines the default thread locale, which 
then determines all of the above.

If you read up the thread, you will see an email by me asking what 
should be good values to initialize user locale from. The patch as 
committed uses only LC_ALL and LANG, due to not finding a good answer to 
the above question. I'm slowly coming to the conclusion that LC_COLLATE 
would be a good answer, if we handle LC_DATE etc. properly (i.e. - 
override the default if it's different). However, I did not do enough 
research to reach a definite answer on this one.

Also, as I mentioned before, I've installed MUI, and will look into how 
%(!*#@@!& it determines it's interface language. Once we have an answer 
to that, we can finally also honor LC_MESSAGES (and LANGUAGE), and get a 
truly locale aware Wine.

>>Even if you are right that it leads to insanity (and I do understand why 
>>you say that, at least for the codepage and collation collision. If 
>>there are any other cases of insanity, do tell), aren't we supposed to 
>>be bug-compatible with Windows?
>>    
>>
>No, if there is no applications depending on it.
>  
>
But if there hadn't been any application depending on it, I wouldn't 
bother, would I? Considering the amount of applications written for 
Unicode (almost nil), it is safe to say that almost EVERY application is 
affected by it, if your environment is set up like that. Like I said 
before, having LANG point at one thing, and LC_CTYPE at another is a 
pretty common setup in Israel.

You can call it wrong, and I would welcome a crusade to fix the common 
Israeli setup. I just don't think rejecting this patch will do anything 
to help the process. Even if I accept your logic, this patch is fully 
GIGO compliant while not breaking anything if your setup is "right".

       Shachar

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