Make wine honor LC_CTYPE and LC_MESSAGES
wine-devel at shemesh.biz
Tue Jul 27 00:12:25 CDT 2004
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".
Lingnu Open Source Consulting ltd.
More information about the wine-devel