by Michael S. Kaplan, published on 2011/09/30 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/09/30/10218499.aspx
So, the question that came up the other day was an interesting one (identifying product details removed both obvious and not-so-obvious reasons:
Michael,
I’m a dev working on a feature kind of like “mail tips” and allow the text to be displayed to be customized by the Administrator. That customized text may be provided in any number of languages, and Outlook should display the one that most closely matches the user’s language settings in Outlook.
I’m contacting you because someone on my team recommended you as an expert in internationalization. I’m looking to get your expertise and knowledge and history in this area to hopefully help my team gain a better understanding of the issues and to hopefully guide us in the right direction.
Our scenario is as follows, the Administrator can specify a set of localization strings, each with an associated “locale” (whether that’s locale name, or an LCID, or something else is unclear – I’d love to get your guidance on this). Outlook is running in a given locale, or the “default” windows locale – which might not have a corresponding Outlook localization strings. This case is of particular interest. We need to support the administrator localizing his custom string into this specific locale (even though office doesn’t have localized strings for it). Additionally, consider a case where the administrator hasn’t localized this string, into this very specific locale, but he or she localized it into a “very similar” locale – we’d want to display that similar locale. For example, imagine if the Administrator localized the string into French, but the user’s settings were for Canadian French – presumably we would want some way to figure out what is the “best” choice given a desired locale to display and a set of available locales to choose to display.
What I’m really asking for is some help in what to use to identify locales and how to accomplish this “best-match” algorithm.
Thanks in advance for your help.
One of the core principles that international support in Windows/Office subscribes to is that there is a difference between the language of the user interface and the language specifying how to format/collate information (SQL Server works under slightly different core principles -- with the split being codepages/collation vs. UI language/formatting).
You can probably see some of the confusion in the question relating to what is a part of the user interface language and what isn't.
We actually have only a very limited number of cases where we support different UI languages that share a common language across two or more locales (and Canadian French vs. Parisian French isn't one of them are thet we really pay heed to).
In fact, despite other potential cases I've mentioned in the past (e.g. Arabic, English, French, Spanish), just:
are all we have in this limited category. Those other business cases simply have never been made convincingly enough, no matter how "self evident" their truths appear to be to folks like me! :-)
When you think about the nature of the differences, one can make a very strong argument to avoid fallback in these limited cases since having the wrong Chinese or the wrong Portugese pop up can be a huge customer satisfaction issue. Having it served up as the UI lanuage seem for the sake of fuzzy matching, or more clever fallback....
The one reasonable case for fallback is in partially localized SKUs -- Language Interface Packs.. But in that case, the system does a good job of fallback al on its own, and there is no need to add fuzzy fallback mechansms atop what exists.
The best tool you can use here is one of two resource loaders (Win32 vs. managed), which will then try to do the best fallback it can.
Though another concern raise itself in my mind: would this planned architecture make "OpenLocalization" a reality for some products? Imagine being able to change lots of the localiztion effort based the user's UI Language. Though the extent of localization that could be overriden is unknown, since the curent scope seems fairly limited (to some specific administrative error messages, where updates would probably be more likely to hit usability concerns than dialect issues)....