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