by Michael S. Kaplan, published on 2010/02/14 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/14/9963164.aspx
I think it was just yesterday that Jacques asked:
Can somebody explain to me the rationale behind why RegionInfo doesn't support the full set of ISO-3166-2/3 codes? Is there more to it than "because nobody spec-ed, implemented, tested, and documented it"?
Well there is certainly more to it than just that.
Though not in a terribly impressive way!
In looking at locales in Windows way back before .NET was even announced (as NGWS -- Next Generation Web Services), the theoretical question of how would all of the stuff in NLS be designed if it were a bit more object oriented, knowing everything that the previous years had taught.
One of the problems was the nebulous nature of locale as anything more than a "collection of stuff separated by language, region, and script."
Before I say anymore I'll just point t where I talked about this a couple of years ago, in CultureInfo subsetting attempts that suck.
In the blog I explain that two different attempts to subset locales in the managed world, i.e.
both were kind of failures, each in their own way.
The current RegionInfo was formed by looking at everything in a locale and isolating the stuff with no language-specific dependencies.
And the unfortunate thing about that approach is that of the 200+ items in a locale, less than a dozen of them that ONLY relate to region with no language dependencies, and less than a dozen of them that ONLY relate to language with no region dependencies. And maybe another less than a dozen are specific to just the script.
The other 85-90% of the stuff still sits in the mix between these concepts and still requires a big bucket whether you call it LOCALE or CULTURE.
Now these three sub-buckets were handled in three very different ways:
None of them map well to what ISO 3166 does.
I won't even get into the GEOID which has other flaws, as I mentioned in CurrentRegion is not based on the GEOID and GEOID -- The LCIDs maligned little brother.... though you can read those blogs for more info on why this is not such an answer either.
But would the kind of RegionInfo that Jacques refers to, one that takes a big stab at everything in ISO-3166, be a better choice for something to have?
Well, maybe.
Though RegionInfo would need to look very different and geared at collecting a much smaller subset than it currently does, to keep the data collection from being a nightmare (leave alone for a second the size explosion of carrying all that data around!).
Now I am long out of the team that owned this stuff back when there even was a team that was actively looking at what th stuff should look like, but if it were something I still had a say in then to be honest after mishandling the bucketization three times in one implementation, I would not be as eager to jump back into the mix to try to change it yet again. Any change here would need to be much more carefully considered -- and especially considered more from the point of view of how people need to use the buckets then how to improve the categorization the data with which the buckets would be filled.
moothong on 14 Feb 2010 8:32 AM:
You must try to learn. And switch between accounts of what happened in Carolina.