https://bugs.winehq.org/show_bug.cgi?id=47872
--- Comment #9 from François Gouget fgouget@codeweavers.com --- SystemPreferredUILanguages=0409 vs 0411 ---------------------------------------
I ran tests where I took control of the VMs and manually tweaked the localed. The result is that an unpatched gdiplus:font succeeds when SystemPreferredUILanguages is 0409 and fails if it is set or starts with 0411.
Here's a diff between two unpatched gdiplus:font runs on w1064:
@@ -32,7 +32,7 @@ SystemDefaultLCID=0409 UserDefaultLCID=0411 ThreadLocale=0411 - SystemPreferredUILanguages=0409 + SystemPreferredUILanguages=0411,0409 UserDefaultUILanguage=0411 ThreadUILanguage=0411 Dll info: @@ -41,6 +41,9 @@ gdiplus:brush skipped dlls/gdiplus/tests/brush.c - gdiplus:customlinecap skipped dlls/gdiplus/tests/customlinecap.c - gdiplus:font start dlls/gdiplus/tests/font.c - +font.c:832: Test failed: wrong face name MS UI Gothic +font.c:840: Test failed: wrong face name MS UI Gothic +font.c:851: Test failed: wrong face name MS UI Gothic font.c:866: fallback font Arial font.c:697: gdiplus: font.c:698: L"Tahoma",-13: EmHeight 2048, LineSpacing 2472, CellAscent 2049, CellDescent 423, FontHeight 15.691406, FontSize 13.000000
The 2020-03-16 patch --------------------
What it does is remove the lfFaceName check against "MS Shell Dlg" so of course it fixes the first failure.
But a few lines down there are two other checks of lfFaceName against "Microsoft Sans Serif" || "Tahoma" and those still fail in the Japanese locale.
https://testbot.winehq.org/JobDetails.pl?Key=67263&f217=exe32.report#k21...
Note that without the patch we get the same failures with different font names in the Chinese VM (test.winehq.org does not have those results because WineTest times out but you can fish them out on the TestBot). But with the patch all failures disappear in the Chinese locale!
Maybe the test should check the SystemPreferredUILanguages value and only perform these tests in a couple of well-known locales (English and French for instance), since the other locales can apparently get different fonts.
Why different SystemPreferredUILanguages values? ------------------------------------------------
By default my Windows 7 Ultimate VM is in the en-US locale.
1. If I start the Control panel, go to "Clock Language, and Region" -> "Change display language" -> "Choose a display language", "Japanese" and then reboot, this is what I get:
SystemPreferredUILanguages=0409 UserDefaultUILanguage=0411 ThreadUILanguage=0411
Incidentally this is how I configured win7u64-1spie9-ja, except I also changed "Administrative" -> "Change system locale..." (and rebooted of course), the formats and country. I see nothing wrong with this approach to setting the locale. I suspect this is how most users with a multi-language Windows version would do it.
I get the same result on Windows 10 when I go through the Settings GUI to change the locale.
2. If instead I use the TestBot's script and run "SetWinLocale --mui ja-JP" to recfigure that VM I get:
SystemPreferredUILanguages=0411 UserDefaultUILanguage=0411 ThreadUILanguage=0411
SetWinLocale changes the local by running intl.cpl on an XML file. This seems to be how an administrator would create a 'CD' that installs Windows in a specific locale. Unfortunately that part is really not very well documented.
Running this method against a Windows 10 VM I get exactly the same results which makes sense since this is how I normally configure the TestBot's Windows VM nowadays because it can mostly be automated.
3. There may be a third case which is when a user an already localized version of Windows on a PC or CD. In the past those Windows versions did not support multiple languages (Windows 10 changed that). I suspect this third case would have looked more like the second case but I cannot verify that.
So I don't know why the two methods I use give different results. I also don't know how to get the same results as method 2 using only the GUI. But I see no reason why one configuration should be considered broken. So I think the tests should work in both cases.