Hi list,
Sorry if this is slightly off topic.
I am having some trouble with a sample program I keep changing to death. This program is written in VC on Windows 2000, and being run on Wine as well. I added a Hebrew menu over an already existing English(US) one. My regional settings say that my global settings are Hebrew, as are my local settings. The two menus both have the same ID, and only the language is different between them. When VC's resource editor displays the menus, it displays one with (English U.S) appended, and the Hebrew one without any extension (implying it thinks this is the default one).
So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French).
Wine behaves as expected. running: wine TestApp Yields an english menu, while LANG=he_IL wine TestApp yields a Hebrew one.
I wouldn't worry so much, except that since we define a bug in Wine as any inconsistancy with Windows, this is a bug. I'm mostly trying to understand why Windows won't do what it's supposed to do, however.
I'm using "RegisterClass" to register a class with the menu identifier passed using "MAKEINTRESOURCE", and then just calling "CreateWindow" to create the window.
Anyone has any ideas or suggestions, or just an opinion whether that should worry us at all?
Shachar
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French).
I revived my old test for FindResource and now I see what are you talking about. LoadStringA/W and FindResourceA/W under Win2000 do search for language resource in the following order: 1. Neutral language with neutral sublanguage 2. LANG_ENGLISH, SUBLANG_DEFAULT 3. LANG_ENGLISH, SUBLANG_NEUTRAL 4. Current locale lang id 5. Current locale lang id with neutral sublanguage 6. Return first in the list
But that means that the whole our internationalization will not work, if we will go that way. But the question I have is: had I made an error when I did the test under Win95OSR2 or MS has changed algorithm since then?
Dmitry Timoshkov wrote:
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French).
I revived my old test for FindResource and now I see what are you talking about. LoadStringA/W and FindResourceA/W under Win2000 do search for language resource in the following order:
- Neutral language with neutral sublanguage
- LANG_ENGLISH, SUBLANG_DEFAULT
- LANG_ENGLISH, SUBLANG_NEUTRAL
- Current locale lang id
- Current locale lang id with neutral sublanguage
- Return first in the list
But that means that the whole our internationalization will not work, if we will go that way. But the question I have is: had I made an error when I did the test under Win95OSR2 or MS has changed algorithm since then?
This defies any explanation in my mind. The current locale should, by any standard calling itself even remotely just, be the first in the list.
In any case, I would like to suggest a possible alternative to 2 and 3. Could it be that it asks for whatever language is considered native for the installation, rather than English (with English being what the both of us see just because we both happen to use an English installed Windows?)
This would make some sense, in an obscure and pervert sort of way, unless you consider the BiDi interface dillema.
Background: Windows 3.1 has introduced a Hebrew version programmed by an Israeli company. It was so bad, that MS introduced Windows 3.11 under the term "Multilinguial windows", almost just so they can put in their own implementation of Hebrew instead. That wasn't much better, however.
By the time Windows 95 came out, both Hebrew and Arabic versions shipped in two flavours. The first was a fully localized version, and the second one was a version that, while supporting Hebrew/Arabic, displayed the entire interface in English. These version were called "Hebrew enabled" and "Arabic enabled" respecively.
By the time Windows 98 came around, the two were shipped on the same CD. You would get a boot time menu that offered to install the localized, or the Enabled versions. I have a sneeking suspicion that that's when the change of behaviour described here was introduced. They probably thought that just because people didn't like THEIR Hebrew interface, they wouldn't like anyone else's. They still had to set the default locale to Hebrew, or DEFAULT_CHARSET would not select HEBREW_CHARSET. In other words, I suspect this change was introduced in or around Windows 98, to compensate for the fact that there was no seperate selection of interface language and of charset (before you laugh, KDE 3.1 suffers from the precise same problem).
The problem was that Windows 2000, the first truely multilingual Windows, while not shipping in two versions (what's the point? Just install the English version and add Hebrew support), apparently meant that you couldn't get Hebrew menus, no matter what you did.
So, I suggest we keep our current algorithm. It seems sane and correct. If people complain, we'll talk about it again (I'll hint that I'll be recommending adding a configuration option to select what to do).
Shachar
-
Dmitry Timoshkov -
Shachar Shemesh