Make wine honor LC_CTYPE and LC_MESSAGES

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>"Shachar Shemesh" <wine-devel at shemesh.biz> wrote:
>
>  
>
>>>As far as I understand what you are trying to do and what the patch
>>>Alexandre committed does is to make the user interface use english
>>>while you still have an ability to type in your native language.
>>> 
>>>
>>>      
>>>
>>No. What I'm trying to do is have none-unicode applications use the 
>>correct codepage according to their LC_CTYPE. That's all I'm trying to 
>>do. While my original patch tried to also choose the interface language, 
>>I removed that part. I think you are simply reading into this patch's 
>>intentions things that are not there.
>>    
>>
>
>Why LC_ALL or LANG don't work for you then?
>  
>
Please reread the patch. They are looked at, just not exclusively. 
LC_ALL overrides everything, and LANG is looked at if no LC_CTYPE (or 
whatever) is used. That's the order Unix does it (man 7 locale).

>>>On my
>>>english win2k with locale set to russian both GetSystemDefaultLCID and
>>>GetUserDefaultLCID return 0419 (russian).
>>>
>>>      
>>>
>>Now I'm not following what you are trying to say. According to my 
>>understanding of Windows, if you installed an English Win2k and set 
>>system locale to Russian, all non-unicode applications you run will 
>>interpret the string of bytes they read from files etc. under a Russian 
>>codepage.
>>    
>>
>
>No, data from any sources doesn't get interpreted by apps, the strings
>are interpreted when they are passed to A family of APIs.
>  
>
Same difference. Still, this interpretation is determined by the system 
locale on Windows, and by LC_CTYPE on Unix. Hence - LC_CTYPE should 
affect system locale.

>  
>
>>If you set the user locale to Russian as well, you will get 
>>dates in European order etc. as well. Your interface language should 
>>remain English. That is the behaviour you are seeing, right?
>>    
>>
>
>You are confusing two different things: language of the user interface
>(you call it the system locale)
>
No. Language of interface, which I call "the language of windows you 
installed".

> and current ANSI code page (you call it
>the user locale).
>
No. I call that the system locale.

> There only one locale of the system which defines
>current ANSI code page,
>
Which is the system locale, taken (according to my patch) from LC_ALL if 
defined, LC_CTYPE if not defined, and LANG if neither are defined. Why 
do you object to that?

> language of the user interface has nothing
>to do with it.
>  
>
Nor was it meant to be affected by this patch (the second version - the 
one that was committed). Nor, coming to it, is it actually affected.

>>It's not. I've installed MUI, and am currently investigating this. I'm 
>>thinking of either having "FindResource"
>>use the interface language as defined by MUI instead of "LANG_NEUTRAL, 
>>SUBLANG_NEUTRAL", or replace entry 9 in "find_entry" with the above 
>>mentioned language. I still have to see how that is defined on Windows 
>>MUI. In any case, I trust there is no argument that Wine should behave 
>>like MUI, right?
>>    
>>
>
>Right, it just should be implemented properly, and not like an one liner
>hack.
>  
>
again - this one liner is not attempting it.

>>Either way, the patch above (second version) had no presumptions to do 
>>what you claim it tries to do, and I therefor think your objection to it 
>>is unfounded.
>>    
>>
>
>My objection is that your patch aiming a good intention does the things
>in the wrong way.
>  
>
I'll repeat - you misinterpret the patch's intention. You therefor come 
to the conclusion that it is a hack. It is neither aimed at affecting 
the user interface language, nor does it in actuality. Please reread the 
second version of the patch.

             Shachar