Dmitry Timoshkov wrote:
"Vincent Béron" vberon@mecano.gme.usherb.ca wrote:
(after a bit more testing) Using only SUBLANG_FRENCH_CANADIAN will display in French on both Windows and Wine. Using only SUBLANG_FRENCH_SWISS will display in English on both Windows and Wine. Using only SUBLANG_FRENCH will display in French only in Windows, English in Wine (with LANG=fr_CA).
So SUBLANG_FRENCH seems to act (on Windows) the same way as a wildcard, matching any of it's sublanguages if an exact match can't be done.
Could you please elaborate a bit, how exactly you did the tests above?
I also tried defining more than one (ie, SUBLANG_FRENCH and SUBLANG_FRENCH_CANADIAN) resources. On Windows it chose the SUBLANG_FRENCH, while in Wine it chose the SUBLANG_FRENCH_CANADIAN. That gets me a bit puzzled though... unless my installation of Windows is set to French, then French Canadian as a fallback (don't know of to check this).
All of this highly depend on the exact language set in your system (be it Windows or Wine).
I've attached my test app. See the results I got eclosed there between #if 0/#endif.
Note, that if your system doesn't support SetThreadLocale() (i.e. you are running Win9x), the system will prefer your current locale settings instead of the provided value and it will influence behaviour of LoadString and FindResource.
As you might see, Wine doesn't behave exactly like Windows, Wine makes a preference for the current locale, Windows prefers to choose LANG_ENGLISH first. As it was discussed previously, Wine's behaviour have to stay as it is now, otherwise all NLS support for built-in DLLs and apps will broke.
I suspect that this depends on the language of Windows you install. When I have some time, I'll play a bit with this. MS also has a version of windows called "MUI", or Multilinugual User Interface. I suspect that that version behaves more like Wine does at the moment, but I have not checked that one either.
In the mean while, let's indeed reverese the patch translating SUBLANG_NEUTRAL->SUBLANG_DEFAULT.
Shachar