Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> 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
