I have noticed some test failures that only happen when I set the locale and display language to Japanese and/or Hebrew in Windows 7. Let me know if I should create bugs for these.
* comctl32:listview (Hebrew and Japanese) listview.c:3822: Test failed: Expected 96, got 112 listview.c:4751: Test failed: Expected 96, got 112
Both correspond to the use of GetDeviceCaps(LOGPIXELSX) so something must be wrong there: todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, rect.right); todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, ret);
* riched20:editor (Hebrew only) editor.c:586: Test failed: EM_POSFROMCHAR reports x=5, expected 8 editor.c:609: Test failed: EM_POSFROMCHAR reports x=5, expected 8 editor.c:640: Test failed: pt.x = 117
All three are related to testing positions past the end of text. Here the fact that Hebrew is RTL probably breaks the test.
* rpcrt4:rpc (Japanese only) rpc.c:171: Test failed: DceErrorInqTextA(deviation...)
Based on the comment it does not seem surprising that this would be language-specific: /* One for which FormatMessage should succeed but * DceErrorInqText should "fail" * 3814 is generally quite a long message */
* shell32:progman_dde (Hebrew and Japanese) progman_dde.c:377: Test failed: Window "?????" was not created in 45 seconds - assumed failure. [S_G:11]
Based on the 'S_G:11' this would correspond to this line: ShowGroupTest(instance, hConv, "[ShowGroup(Startup,0)]", DMLERR_NO_ERROR, "Startup", StartupTitle, TRUE, DDE_TEST_SHOWGROUP|testnum++);
* shlwapi:ordinal (Hebrew only) ordinal.c:1721: Test failed: expected (ùáú 16 ôáøåàø 2013), got (??? 16 ?????? 2013) ordinal.c:1729: Test failed: expected (ùáú 16 ôáøåàø 2013), got (??? 16 ?????? 2013) ordinal.c:1743: Test failed: expected (ùáú 16 ôáøåàø 2013) got (??? 16 ?????? 2013) for date part ordinal.c:1757: Test failed: expected (ùáú 16 ôáøåàø 2013) got (??? 16 ?????? 2013) for date part ordinal.c:1929: Test failed: expected (L"\05e9\05d1\05ea 16 \05e4\05d1\05e8\05d5\05d0\05e8 2013") got (L"\200f\05e9\05d1\05ea \200f16 \200f\05e4\05d1\05e8\05d5\05d0\05e8 \200f") for date part ordinal.c:1955: Test failed: expected (L"\05e9\05d1\05ea 16 \05e4\05d1\05e8\05d5\05d0\05e8 2013") got (L"\200f\05e9\05d1\05ea \200f16 \200f\05e4\05d1\05e8\05d5\05d0\05e8 \200f") for date part
Note that while the above test was run with a Hebrew locale and display language, I get similar errors when running the test in the Japanese locale with the French display language: ordinal.c:1721: Test failed: expected (2013N216ú), got (2013?2?16?) ordinal.c:1729: Test failed: expected (2013N216ú), got (2013?2?16?) ordinal.c:1743: Test failed: expected (2013N216ú) got (2013?2?16?, 8) for date part ordinal.c:1757: Test failed: expected (2013N216ú) got (2013?2?16?, 8) for date part
Looks like both encoding and RTL checks. I think the translation is non-UTF-8 (At least it was like that when I was working with .rc files).
Nowadays I believe that the PO should be UTF-8 so it shouldn't matter.
Kind regards, Yaron Shahrabani
<Hebrew translator>
On Sun, Feb 17, 2013 at 11:52 AM, Francois Gouget fgouget@free.fr wrote:
I have noticed some test failures that only happen when I set the locale and display language to Japanese and/or Hebrew in Windows 7. Let me know if I should create bugs for these.
comctl32:listview (Hebrew and Japanese) listview.c:3822: Test failed: Expected 96, got 112 listview.c:4751: Test failed: Expected 96, got 112
Both correspond to the use of GetDeviceCaps(LOGPIXELSX) so something must be wrong there: todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16,
rect.right); todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, ret);
riched20:editor (Hebrew only) editor.c:586: Test failed: EM_POSFROMCHAR reports x=5, expected 8 editor.c:609: Test failed: EM_POSFROMCHAR reports x=5, expected 8 editor.c:640: Test failed: pt.x = 117
All three are related to testing positions past the end of text. Here the fact that Hebrew is RTL probably breaks the test.
rpcrt4:rpc (Japanese only) rpc.c:171: Test failed: DceErrorInqTextA(deviation...)
Based on the comment it does not seem surprising that this would be language-specific: /* One for which FormatMessage should succeed but * DceErrorInqText should "fail" * 3814 is generally quite a long message */
shell32:progman_dde (Hebrew and Japanese) progman_dde.c:377: Test failed: Window "?????" was not created in 45
seconds - assumed failure. [S_G:11]
Based on the 'S_G:11' this would correspond to this line: ShowGroupTest(instance, hConv, "[ShowGroup(Startup,0)]", DMLERR_NO_ERROR, "Startup", StartupTitle, TRUE, DDE_TEST_SHOWGROUP|testnum++);
- shlwapi:ordinal (Hebrew only) ordinal.c:1721: Test failed: expected (ùáú 16 ôáøåàø 2013), got (??? 16
?????? 2013) ordinal.c:1729: Test failed: expected (ùáú 16 ôáøåàø 2013), got (??? 16 ?????? 2013) ordinal.c:1743: Test failed: expected (ùáú 16 ôáøåàø 2013) got (??? 16 ?????? 2013) for date part ordinal.c:1757: Test failed: expected (ùáú 16 ôáøåàø 2013) got (??? 16 ?????? 2013) for date part ordinal.c:1929: Test failed: expected (L"\05e9\05d1\05ea 16 \05e4\05d1\05e8\05d5\05d0\05e8 2013") got (L"\200f\05e9\05d1\05ea \200f16 \200f\05e4\05d1\05e8\05d5\05d0\05e8 \200f") for date part ordinal.c:1955: Test failed: expected (L"\05e9\05d1\05ea 16 \05e4\05d1\05e8\05d5\05d0\05e8 2013") got (L"\200f\05e9\05d1\05ea \200f16 \200f\05e4\05d1\05e8\05d5\05d0\05e8 \200f") for date part
Note that while the above test was run with a Hebrew locale and display language, I get similar errors when running the test in the Japanese locale with the French display language: ordinal.c:1721: Test failed: expected (2013 N2 16 ú), got (2013?2?16?) ordinal.c:1729: Test failed: expected (2013 N2 16 ú), got (2013?2?16?) ordinal.c:1743: Test failed: expected (2013 N2 16 ú) got (2013?2?16?, 8) for date part ordinal.c:1757: Test failed: expected (2013 N2 16 ú) got (2013?2?16?, 8) for date part
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.
On Sun, 17 Feb 2013, Yaron Shahrabani wrote:
Looks like both encoding and RTL checks.
Did you mean that for a specific test?
I think the translation is non-UTF-8 (At least it was like that when I was working with .rc files).
Nowadays I believe that the PO should be UTF-8 so it shouldn't matter.
Yes, I don't think there should be encoding issues, at least as far as the resources are concerned. Note that the question marks in some failure messages are probably just because the Wine tests use ANSI functions to report the errors. But the strings actually being tested are probably proper Unicode strings.
On Mon, Feb 18, 2013 at 12:48 PM, Francois Gouget fgouget@free.fr wrote:
On Sun, 17 Feb 2013, Yaron Shahrabani wrote:
Looks like both encoding and RTL checks.
Did you mean that for a specific test?
No I was talking about all the Hebrew test in general.
I think the translation is non-UTF-8 (At least it was like that when I
was
working with .rc files).
Nowadays I believe that the PO should be UTF-8 so it shouldn't matter.
Yes, I don't think there should be encoding issues, at least as far as the resources are concerned. Note that the question marks in some failure messages are probably just because the Wine tests use ANSI functions to report the errors. But the strings actually being tested are probably proper Unicode strings.
So maybe the checks should be replaces?
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Did you change ANSI codepage? As you may know, Japanese (codepage 932) is not compatible with Windows 1252 except for 7-bit ASCII characters. So you have to change codepage settings, Language for Non-Unicode Programs, in the Control Panel.
Most of wine test try to run ANSI version of APIs. Language specific texts (e.g. error messages, startup folder name, day of week names, font face name) aren't represented properly in other codepages.
On Sun, 17 Feb 2013 10:52:06 +0100 (CET), Francois Gouget wrote:
comctl32:listview (Hebrew and Japanese) listview.c:3822: Test failed: Expected 96, got 112 listview.c:4751: Test failed: Expected 96, got 112
Both correspond to the use of GetDeviceCaps(LOGPIXELSX) so something must be wrong there: todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, rect.right); todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, ret);
It seems that this size depends on window appearance. I changed font size of "Icon" in "Window Color and Appearance" window. The test was passed in "Tahoma 8", but failed in "Meiryo 9", Japanese default settings in Windows 7. The default settings were "Tahoma 8" in Windows XP era, thus the testbot doesn't complain about this.
(skip Hebrew topic...)
rpcrt4:rpc (Japanese only) rpc.c:171: Test failed: DceErrorInqTextA(deviation...)
Based on the comment it does not seem surprising that this would be language-specific: /* One for which FormatMessage should succeed but * DceErrorInqText should "fail" * 3814 is generally quite a long message */
Yes, I verified DceErrorInqTextA returned language-specific message on native Windows. I guess this caused by ANSI conversion error. But it is curious why test on line 164 was succeeded. Anyway, these tests succeeded on my PC, Japanese Windows 7 (x64).
shell32:progman_dde (Hebrew and Japanese) progman_dde.c:377: Test failed: Window "?????" was not created in 45 seconds - assumed failure. [S_G:11]
Based on the 'S_G:11' this would correspond to this line: ShowGroupTest(instance, hConv, "[ShowGroup(Startup,0)]", DMLERR_NO_ERROR, "Startup", StartupTitle, TRUE, DDE_TEST_SHOWGROUP|testnum++);
Ditto. There is ANSI conversion error, too. I guess "?????" is localized startup folder name that didn't convert into Windows 1252 characters. This test also succeeded on my PC.
Regards, Akihiro Sagawa
On Mon, 18 Feb 2013, Akihiro Sagawa wrote:
Did you change ANSI codepage? As you may know, Japanese (codepage 932) is not compatible with Windows 1252 except for 7-bit ASCII characters. So you have to change codepage settings, Language for Non-Unicode Programs, in the Control Panel.
Not specifically no. My understanding is that Windows 7 has essentially three separate locales. In this case we see that the test ran with: http://test.winehq.org/data/c41f6add0563252a5809c3c83cbb6a6e6f81c2d9/win7_fg...
* SystemDefaultLCID = 409 This is the system locale and it is set to English. http://www.sisulizer.com/_img/codepage-problems/w7-region-and-language-admin...
* UserDefaultLCID = 40c The user locale here is set to French and determines the date / time format, number format, currency, etc. http://www.sisulizer.com/_img/codepage-problems/w7-regions-and-languages-for...
* UserDefaultUILanguage = 411 And this is the 'Display Language' which determines which language will be used for the GUI. Here it is set to Japanese. http://www.sisulizer.com/_img/codepage-problems/w7-region-and-language-langu...
It's important for Wine to know which setting each API is impacted by. That's why I normally try to use different locales and display languages. I must admit I did not particularly pay attention to the system locale setting so all my VMs have it just set to English. But I'd like to keep it set differently from the others.
I'd further argue that it's up to Wine's conformance tests to skip tests that don't make sense in the current environment. For instance there are tests where compare a result against a known English string, so these tests are skipped if running in a non-English locale (and here checking the right locale out of the three is crucial).
Do you know of a specific test that fails because the system locale is currently set to English?
On Mon, 18 Feb 2013 20:55:53 +0100 (CET), Francois Gouget wrote:
Do you know of a specific test that fails because the system locale is currently set to English?
I'm not sure about this, but it probably works fine except for progman_dde.c:377. Because few tests rely system locale or ANSI codepage as you observe. If I find another issue related locales, I'll send a patch or file a bug.
Akihiro Sagawa
-
Akihiro Sagawa -
Francois Gouget -
Yaron Shahrabani