by Michael S. Kaplan, published on 2011/06/30 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/06/30/10181768.aspx
This blog reminds me of "Fall over" is not the same thing as "fall back" for [hopefully] somewhat obvious reasons....
It is the most simple and innocent of questions that can tend to add to the most convoluted of answers.
Like yesterday.
The question was:
Hello,
I’m wondering where could I get a list of languages with info regarding the preferred fallback language for each of them.
Thanks for your help.
This is just such a question.
Unfortunately, there are two different answers.
I mean, at least two answers.
Even after you ignore the kinds of questions that issues like Raymond's The many ways of converting a string from one language to another bring up.
So in one case, you have the fallback described by the Win32 GetLocaleInfoEx/LOCALE_SPARENT and managed CultureInfo.Parent chain.
This one will, for example, tell you that uk-UA (Ukrainian - Ukraine) falls back to uk (Ukrainian - Neutral), which falls back to Invariant.
And in the other case, you have the fallback officially determined for language resources.
This one will, for example, tell you that uk-UA (Ukrainian - Ukrainian) falls back to ru-RU (Russian - Russia), which falls back to English.
Um.
Which one is right?
In managed code, the first one is right -- it is how the resource loader works. Though in .Net 4.0 it co-opts some of the native resource fallback list.
In native (Win32) code, it is a complicated system that builds a UI language list built up from principally the second one, though essentially including the first one as well in most cases.
If (given the fact that Windows uses both native and managed code) this sounds vaguely insane to you, then you should vaguely congratulate yourself for being vaguely on track.
Because all of this way to freaking complicated for words, for no good reason.
Especially since the LOCALE_SPARENT/CultureInfo.Parent scheme should be able to return the "combined" list of (for example):
uk-UA --> uk --> ru-RU --> ru --> en-US --> en --> Invariant
So that the rules of both lists can be accommodated, in ways that users can appreciate the results of and developers query and use as they need (from either native or managed code).
For now we just live with the very different scenarios leading to very different results....
Jan Kučera on 30 Jun 2011 11:25 PM:
Well actually the interesting part to me is what should I fallback to from sr-Latn-BA and similar cases... to sr-Cyrl-BA or sr-Latn (and vice versa)? Should I be giving more importance to the regional differences (eg. date format, currency etc.) or to the script - maybe people could happen to not to know the other script?
Peter Krefting on 1 Jul 2011 12:36 AM:
Well, in reality, it is a personal preference, so instead of specifying a single language for a locale, I'd like to specify a list of languages, just like I do in the language settings of my web browser (I have mine set up as sv --> nb --> no --> da --> nn --> en --> de). Mac OS X lets me do this, and I sometimes do get Norwegian or Danish UI in software that I install that do not have Swedish localization, and I do prefer that to English, but I do know people who would not like that to happen.