by Michael S. Kaplan, published on 2010/01/16 12:11 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/01/16/9949421.aspx
The question was one that has been asked before:
Our app could be deployed on Windows XP/2003 which dozen’t support en-SG (English-Singapore) and en-MY (English Malaysia), two cultures that we are shipping.
We are setting the CurrentUICulture explicitly and deploying the appropriate satellite assemblies. My question is: will this just work on XP/2003 or would we have to register custom cultures on these operating systems?
This issue is one that I often blame on the way UICulture keys off of CultureInfo, in particular as I described in Two things that suck about CurrentUICulture, part 1 and part 2. This keeps an architecture that could have worked just based on names without requiring cultures to exist from reaching its full potential. From working in the specific scenario of supporting cultures that may or may not exist on a given machine, on that machine.
Now the workaround is straightforward enough - a custom culture on the machine will let the culture work on that machine.
But this is an honest step backward from the world of native resources in the pre-Vista era, when a single binary could contain multiple languages keyed off of LCID values and it did not matter whether the LCID was understood by the machine or not.
And while on the topic, the Vista and later story is also a step backward in some ways, since it is also name dependent and the locale must exist on the machine. Though the old, all language resources in one binary, should still work there a fact that would make this more of a step sideways since it primarily affects the enhanced MUI story rather than the resource loading story that predates MUI entirely.
Managed code is better than native code in one very important way: the custom culture solution works much better there overall, as I pointed out in Thinking about MUI is making me bipolar. Though that bug is fixed in Windows 7 (verified just a moment ago, with random-piece-of-crap-locale working just fine there for native MUI too.
But both still fail in the "culture/locale not on the box" scenario....
referenced by