-
Bug
-
Resolution: Invalid
-
P3: Somewhat important
-
None
-
4.6.2
-
None
-
Windows XP, Vista, WIn7
-
363e4f06bea8dbe9879bc2fc6328f37815233196
I have found a bug in the QLocale system when working with windows.
This effect XP, Vista and Win 7.
Im honestly a bit surprised no one has hit it before.
First, the simple bug, which is mostly a documentation bug.
Through out the documentation, you have references to QTextCodec::locale() which is GONE and is only in Qt 3 support.
However, all it does is turn around, and return QLocale::system().name(). The funny part, QLocale::system() has a see also for QTextCodec::Locale()..
It really should be cleaned up.
However, here is the bigger bug. On windows, there really are three separate sets of locale settings. Each "set" can have the current UI value vs the System Default value, Ie, if the current user has another language set then the base OS installed language.
Note, I could not find the full set of win32 calls for each of these values. I could find the .Net calls, inside the CultureInfo class.
The three sets of values are, 1) Keyboard setting, 2) Formats setting, 3) Displayed language. Unfortunately, while they are tied together, they are independent values. You could, in theory have a English Language display, using German Formats (date, time etc) and a French keyboard..
If the users machine is installed as german, Qt returns the correct value (all three are set to german). However, what Im finding, is if it's a English (US) machine, the user quite often will change the language display, but not the formats (they use the windows language bar)
This cause Qt, to INCORRECTLY return the wrong locale information. The language returned is dependent on the Formats information, not the current language.
The primary issue, is in the function winIso639LangName and winIso3116CtryName.
For lang name, rather then using GetLocaleInfo, using GetUserDefaultUILanguage works, to return the current language. But I cant find the correct "country".
Im not sure of the best solution, in the .net world, they have gone to a "System" vs "UI" set of locales, maybe a new static function that is returns these values.
I wound up having to write my own GetUserDefaultUILanguage based functionthat uses the Qt internal code winLangCodeToIsoName to decipher the LANGID returned.
Scott