Four cases where I don't like ResolveLocaleName (and you shouldn't either!)

by Michael S. Kaplan, published on 2012/04/23 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/04/23/10296348.aspx


In the past, I've written many times about ConvertDefaultLocale -- you can check them out here.

Mostly, I just complain about weird silliness that the function does in it's strange efforts to convert neutral LCIDs to specific LCIDs, and to try to bridge differences between the .Net Framework and old versions of Windows.

But there is another function, one that is pretty awful too. In some ways even worse, perhaps?

The function I mean is ResolveLocaleName, added in Windows 7.

It's one of those cool functions that is documented as "Applies to: desktop apps | Metro style apps".

However, it isn't really very cool in its implementation.

It's algorithm:

  1. Take the name it was given, see if it is a valid locale of some kind;
  2. If the name in step #1 a valid locale, return the "specific" version of it if it's a neutral or the locale's name if it isn't;
  3. If the name in step #1 isn't a valid locale, then strip the right-most hyphen delimited portion of the name;
  4. If the name in step #3 is not an empty string, start again at step #1 with that new name.

Technically it is slightly more complicated than this, but the step are good enough for our current purposes.

Now it does some good things.

For example en-Latn-US becomes en-US and both fil-Latn and fil-Latn-PH become fil-PH and ug-Arab-CN becomes ug-CN.

I call this Case #1, the "fix the problem of including script names when we don't use them and other such bugs" case.

But it also does some worse things.

Like en-Latn-AU also becomes en-US.

I call this Case #2, the "it could have been smarter" case.

And even worse things.

Like zh-Hant-TW becomes zh-HK.

I call this Case #3, the "geopolitically stupid that begs for an exception in the code" case.

And some much worse things.

Like en-Cyrl-TT also becomes en-US.

I call this Case #4, the "morph ridiculous combinations of tags to valid locales" case.

And then some downright ridiculous things.

:Like en-CanYouBelieve-THISCRAP also becomes en-US.

I call this Case #5, the "what the hell were we thinking that day?" case.

How many people can imagine better ways this function could have been implemented?

Knowing (for example) that:

We could have been tremendously smarter here.

And you should be, yourself. And not follow our (much poorer) example in this case.

I have no dev interviews at the moment, but if I did this might be high on my list of potential questions: doing ResolveLocaleName better....


Doug Ewell on 23 Apr 2012 7:11 AM:

OMG. Didn't anyone responsible for this method read BCP 47? At all?

Michael S. Kaplan on 23 Apr 2012 7:58 AM:

I wouldn't want to speculate on that! :-)


Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2012/08/07 ResolveLocaleName cleans up and flies right

2012/08/07 ResolveLocaleName cleans up and flies right

2012/06/28 You've got to ACCentuate the positive (or perhaps it would be better not to be so quick to do so!)

2012/05/17 That 'keyboard culture list' you may have heard so much about

go to newer or older post, or back to index or month or day