Wine and locales

Dmitry Timoshkov dmitry at baikal.ru
Thu Jul 29 05:49:10 CDT 2004


"Shachar Shemesh" <wine-devel at 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.

-- 
Dmitry.




More information about the wine-devel mailing list