"Shachar Shemesh" wine-devel@shemesh.biz wrote:
If the user's locale is broken, it's perfectly ok in my book for Wine to be broken too. Picking a random environment variable and saying "We will use this one and not that one" is utter nonsense. Just so things are clear, picking LC_ALL and LANG for the system locale, but not LC_CTYPE is precisely that - picking random variables as representing of functionality typically provided by other variables.
LC_ALL and LANG are not random variables, that's what glibc uses for internal locale setup.
The flip side of your argument regarding broken locales now being broken on Wine as well is that, if this patch is reverted, perfectly valid locales (such as mine - LANG=en_US, LC_CTYPE=he_IL) are broken.
Your locale is broken, and I already explained why. You are lucky that en_US has no conflicting with he_IL characters in the upper ASCII table. Just replace en_US by fr_FR, de_DE or ru_RU. Why are you ignoring this fact?
Now which do you prefer? Broken setups not being "fixed", or valid setups being broken?
I prefer not introduce potentially confusing things. I'm still waiting for the test cases and explanations what exactly APIs are affected by system/user locale in Windows and what users should expect when they have different system and user locale. Until you answer that questions I don't see how you would argue that your patch is correct and does exactly the same thing as supposed to happened under Windows.