"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.
How I did my test: 1. Uncomment all resource strings in locales.rc. If you want, you could add your own resource strings. Make N = 1. 2. build the test. 3. Run test.exe 0x40C (0x40C == LANG_FRENCH,SUBLANG_DEFAULT). Note that SUBLANG_FRENCH == SUBLANG_DEFAULT). 4. Write down the result under number N. N = N + 1. 5. Comment out the found resource. 6. Goto 2.
-- Dmitry.