by Michael S. Kaplan, published on 2005/07/06 02:30 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/07/05/435885.aspx
For some time now, the model being used for neutral locales in Windows, described in this post, has been geting more and more problematic.
After all, there are more and more new neutral locale LCID values that do not look like ordinary PRIMARYLANGID values. Like 0x7c04 for Traditional Chinese. And these values currently do not work well with ConvertDefaultLocale.
I guess we on the Windows side could claim that since Windows did not return the value, it is under no obligation to accept it. And we could say that the people generating the values are the ones who made the mess; they should be the ones to fix it.
Unfortunately, we are not only the victims of the crime here, we are also the perpetrators. So now is not the time to get defensive, since no one really cares what "aspect" of us is at fault. We should just make it work properly.
Luckily there are only a few cases. :-)
It is also important for you (the customer) to do something, too. When you are using the macros to construct LCID values that you make sure you are using the values properly and building the LCIDs correctly. Use the right SUBLANGID value from the list, rather than just assuming that SUBLANG_DEFAULT is good enough. Since sometimes it is not!
But we'll take care of ConvertDefaultLocale -- it needs a little tweaking to handle some of these corner cases....
This post brought to you by "փ" (U+0583, a.k.a. ARMENIAN SMALL LETTER PIWR)
referenced by