"Shachar Shemesh" wine-devel@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?
That's not how Windows does this, at least to my understanding.
That is precisely how windows does it.
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.
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) and current ANSI code page (you call it the user locale). There only one locale of the system which defines current ANSI code page, language of the user interface has nothing to do with it.
I don't know how MUI enabled Windows versions implement that functionality, but I don't think that it's just the system locale.
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.
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.