Wine and locales
wine-devel at shemesh.biz
Fri Jul 30 05:16:00 CDT 2004
Filip Navara wrote:
> Shachar Shemesh wrote:
>> What I don't get is - how can depending on the thread/user locale
>> ever fail?
> Maybe I haven't expressed myself clearly. What I mean is that it does
> the comparsion of the strings first with the thread locale and if that
> returns negative result (string s not equal) then it tries to compare
> the strings again using the system locale.
If that's the case, that's frightening. If the strings are not the same
according to user locale (thread locale, more precisely), I *want* them
to be reported different. So what if under another locale they may be
>> Only if you have the order off the top of your head, and it is NOT
>> the one outlined in "find_entry" (dlls/ntdll/resource.c). I.e. - if
>> you think the one in find_entry is ok, don't waste your time on
>> writing test cases.
> I think "find_entry" is almost correct. Only honouring the the default
> UI lanaguage is missing (as introduced in W2K).
Yes, that's what I'm trying to work on here.
> I think it belongs between step 3. and 4. and that the user default UI
> language (GetUserDefaultUILanguage) is tried first and system default
> UI language (GetSystemDefaultUILanguage) just after that.
A. I don't think we are going to have both. No point, and no place to
initialize it from. I may reconsider when Wine has a multi-user
B. The docs seems to suggest that the thread locale doesn't affect
resource loading at all any more. Is that a bug in the docs? I was
considering simply replacing everything that says "thread locale" with
Lingnu Open Source Consulting ltd.
More information about the wine-patches