Wine and locales

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>"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.
>  
>
Ignoring LC_CTYPE is as random as ignoring any other one. For the 100th 
time, we are not ignoring LC_ALL and LANG. We are simply ALSO looking at 
LC_CTYPE.

>>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?
>  
>
Because it's irrelevant whether there are broken locales that have 
LC_CTYPE different than LANG. The right question is whether there are 
NON broken locales of that type. Luck has nothing to do with it. If the 
setup I'm using was not working, I wouldn't be using it. Another 
interesting question is whether there are non-broken Unix locales that 
result in a broken Wine locale as a result of this patch. The answers, 
as you correctly state in this very question, is YES and NO 
respectively, meaning there appears to be no base in reality for your 
categorical claim that ANY setup with LC_CTYPE is broken.

In other words - my system is running such a locale. Why is it that you 
wish to break my setup? Especially since it doesn't affect your setup at 
all!

>>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.
>  
>
We have a property called "LC_CTYPE" on Unix. We have a property called 
"System locale" on Windows. They are both documented and observed to do 
exactly the same. Mapping one to the other seems the right thing to do.

There is no need to create an elaborate system of test cases just so I 
can prove something which appears to be right is really right. If you 
are so certain it's wrong, why don't you do one of two things:
1. Show us that LC_CTYPE and system locale are NOT the same thing.
2. Show us what system APIs functionality is broken by this patch.

Please bear in mind that I can't think of a single case of 2 above for 
which the answer would be "System locale should not be affected by 
LC_CTYPE". I am much more likely to think "the specific API you found to 
break is the curl pit". I am, however, open to be shown wrong on this.

The most curious thing for me is that this patch does not even affect 
your setup. If you didn't touch LC_CTYPE (as you claim no one should), 
why should you care about this patch? It will still take system locale 
from LANG if LC_CTYPE is not defined.

In other words, this patch fixes Wine on my system without breaking it 
on yours. Any system on which it does break is a system you 
categorically call broken to begin with (LC_CTYPE points elsewhere from 
LANG). Why do you object so much?

             Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/