by Michael S. Kaplan, published on 2010/03/08 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/03/08/9973914.aspx
The other day, Dave asked a question on a list I am on but usually don't pay enough attention to unless the title jumps out at me:
Good morning.
I’m noticing a weird mismatch when calling RegionInfo.DisplayName and was hoping someone could help out.
For a lot of languages, it seems to work fine but on German and Turkish I am seeing a problem.
Problem:
I am trying to call the ActivateServerAutomatic function for the Win32_TSLicenseServer WMI class. To do so, I need to set a few properties, including the CountryRegion.This seems to take the localized name for a country and in my case I want to always set it to United States.
To do so, I am creating a RegionInfo object and then getting the DisplayName property.
On German, this returns “Vereinigte Staaten von Amerika” which causes the WMI call to fail.
So I went to look in control panels for the list of countries the OS recognizes and it seems like the OS uses “Vereinigte Staaten” for United States. Notice it is missing the “von Amerika” part.
When using the short version recognized by the OS, the WMI call succeeds.
Question:
Where is this mismatch coming from and is there a different way I can get the localized name of a country that will match the OS and work in all languages?I actually need this in powershell so a solution either in powershell script or .Net will work.
Thanks for the help,
David
Not too long after, a member of my former former team provided a response:
The display name is the localized version of the name. They don’t match presumably because they were localized at different times by different people. To my knowledge there is no design goal for these to match, especially since .Net returns consistent results for this value on any platform that it is run on.
You can get the value from the OS by p/invoking GetLocaleInfoEx with LCType of LOCALE_SLOCALIZEDCOUNTRYNAME.
Before doing that though, I would try using the TwoLetterISORegionName. I would hope that their API is flexible enough to handle that.
Now his response was accurate insofar as the differences between .Net and Windows (something I have pointed out before for a myriad of issues, including the different localizers in different divisions and how there were bound to be differences that we were not always trying to keep in sync as a design goal), there is more going on here.
Because Dave was looking at a specific part of Windows in doing his comparison:
So I went to look in control panels for the list of countries the OS recognizes and it seems like the OS uses “Vereinigte Staaten” for United States. Notice it is missing the “von Amerika” part.
This made me wonder.
I mean sure he may have been think about the locale list:
which has "English (United States)" in it.
But wouldn't the original question be looking more for strings that stood on their own, like in the next tab:
I wasn't really sure, but it made sense to wonder, I think.
After all, this list is GEOID based, not based on the locale data like RegionInfo is (as I implied in CurrentRegion is not based on the GEOID).
Of course thinking about Dave's original concern, the GEOID list almost makes more sense than anything coming out of the other NLS or System.Globalization data anyway, since the bar to get on the GEOID list is pretty minimal (the bar to get into the locale list is huge, by comparison!). I would imagine Microsoft would be willing to license terminal services to a larger list of countries rather than a smaller one! :-)
Thus the best answer may well be to look into GetGeoInfo with the GEO_FRIENDLYNAME, a value that is localized into the language Windows is localized into. That list is probably the same as the ones WMI's resources would be localized into, too....
And the friendly name does have a design goal to stay in sync to a point, though the GEOID's official name much moreso!