Make wine honor LC_CTYPE and LC_MESSAGES
Shachar Shemesh
wine-devel at shemesh.biz
Mon Jul 26 02:49:58 CDT 2004
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
More information about the wine-devel
mailing list