Dmitry Timoshkov wrote:
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."Shachar Shemesh" <[EMAIL PROTECTED]> 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.
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.
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.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.
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".
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
