by Michael S. Kaplan, published on 2007/03/22 06:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/22/1929762.aspx
Marvin asked in the Suggestion Box:
Looks like GetLocaleInfo(0x46C, LOCALE_SISO639LANGNAME,...)
returns "ns" on XP. Which is not a legal ISO-639-1 abbreviation. Should have been "nso" from ISO-639-2.
Is it a bug or something by [unimaginable] design?
Yes, Marvin is correct. The locale represented by the LCID 0x046c (Sesotho sa Leboa - South Africa) should never have returned a two-letter code since it has no two letter ISO 639 code.
There are a few such mistakes that can be found in the code from the various ELK locales that shipped with XP SP2 and after XP SP2.
I don't really have an excuse to claim here, it was a transitional period for the custodian of the data and there were some misunderstandings about how to produce some of the data. It is the sort of thing that could normally be caught in review but perhaps the eagerness people had to see some of this support they missed a few things.
These problems were fixed in Vista, for what its worth (it is actually one of the issues behind differences between XP and Vista that were discussed in this post, though not the cause of problems described in this other post). As was the process for reviewing and verifying this kind of data....
Sorry about that. :-(
This post brought to you by ⧳ (U+29f3, a.k.a. ERROR-BARRED BLACK CIRCLE)
# Marvin on 22 Mar 2007 2:31 PM:
Ok. Sh^H^Hbugs happen. ;-)
Is there an authoritative list of non-standard names returned by LOCALE_SISO639LANGNAME (and by LOCALE_SISO3166CTRYNAME if those exist) on all Windows versions?
# Michael S. Kaplan on 22 Mar 2007 3:04 PM:
I do not know of such a list, no. But the actual amount of them is not terribly huge (thankfully!).
# Marvin on 22 Mar 2007 3:30 PM:
The reason I am interested in this is that I am working on a portable "language id" class that uses ISO stuff as its canonical representation but obviously has to be able to interoperate with LANGID on Windows.
I can handle broken LOCALE_SISO639LANGNAME by exhaustive testing on existing Windows versions but having an authoritative table from MS would help a lot.
Obviously in any event I will still have to do something sensible when I hit a new bug on future Windows that do not yet exist but at least I want to be safe for what exists now ;-)
# Michael S. Kaplan on 22 Mar 2007 4:16 PM:
Well, for that you really should use the downlevel NLS dll (and the LOCALE_SNAME on Vista) to convert between locale names and LCIDs, not trying to construct the names independently. This will allow you to avoid the bugs, and it will also allow you to get the right results in all cases, including ones where script info is also needed....
# Marvin on 22 Mar 2007 4:24 PM:
And bring yet another DLL? Nah...
Then I still need the individual parts for other reasons so "take everything" API wouldn't work well.
Anyway since it is a bug probably somebody at MS should make a KB out of it.
# Michael S. Kaplan on 22 Mar 2007 4:46 PM:
Which won't help you here, really....
Why not compromise? Download the DLL, use it to enumerate all of the data that you will hardcode into your own table?
# Alexey Provotorov on 26 Mar 2007 4:11 AM:
Sorry in advance, if the message is a bit offtopic, but I think it is somehow related to incorrect work of NLS API for the new XP SP2 locales.
In XP SP2, when we set system locale to any from the newly added list (e.g., Zulu), DAO 3.6 cannot create or open database. The following VB6 line returns E_INVALIDARG:
Set DB = DBEngine.CreateDatabase("c:\temp.mdb", dbLangGeneral, dbVersion40)
The "dbLangGeneral" parameter instructs DAO to use ANSI-1252 code page (Note that the same value is returned by the GetACP() API function for the Zulu locale).
Changing system locale to any of the pre-SP2 values resolves the problem.
We suspect that some of NLS API functions called inside DAO.DBEngine.CreateDatabase() method returns an invalid value, so DAO just can't handle it. Could you shed some light on this, please?
Thanks in advance for your help!
# Michael S. Kaplan on 26 Mar 2007 4:21 AM:
That is a DAO/Jet bug, due to their collation list being approximnately NINE YEARS behind Windows. Nothing to do with NLS unless one thinks the bug is supporting new languages rather than being tolerant of new ones being supported....
# Michael S. Kaplan on 26 Mar 2007 4:52 AM:
I am checking to see if this is an issue they are aware of and if so whether a fix is pending....
# Alexey Provotorov on 26 Mar 2007 5:25 AM:
Thanks for the quick answer!
I would have understood DAO team's point if we had passed Zulu LANGID inside DBEngine.CreateDatabase() method. But we use dbLangGeneral here, which is defined as:
Const dbLangGeneral = ";LANGID=0x0409;CP=1252;COUNTRY=0"
That's why we think that something returned from the NLS API is "indigestible" for DAO. Or do just they compare GetSystemDefaultLCID() to a some hard-coded list of collations?
Thanks again for your help!
# Michael S. Kaplan on 26 Mar 2007 5:49 AM:
It is hard to know exactly what the exact bug is here, but it does not matter -- the fault lies in the most intolerant. :-(
You actually cannot specify any language outside of their known lang list.
Given that there are actually XP RTM languages that are also not supported in the timeframe here, I supect there are a few additional locales that might fail here, too....
# Michael S. Kaplan on 26 Mar 2007 2:31 PM:
More info!
They have a fix available for this bug.