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:

• every valid locale has the knowledge - via GetLocaleInfoEx(... LOCALE_SSCRIPTS, ...) -- of valid scripts that may or may not be specified, and so on;
• the practice of simply stripping information rather than conditionally adding it back can be replaced by one that intelligently processes these items.

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:

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

referenced by

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