When Does Someone Replace a Windows (or .Net) Locale?
Windows Vista and .Net 2.0 support custom locales. A couple days ago Michael mentioned to me that people were wondering when someone would actually replace a built-in locale. For new custom locales, its fairly easy to see why people would want to make a new locale, like for Fijian (Fiji) if they lived there since we don't provide a Fijian locale. What's less clear is why someone would want to replace a perfectly good "built-in" locale.
For en-US, you could suppose that the data was perfectly fine and we've had no complaints. We've mentioned some possible use cases, such as a company standardizing on a 24 hour clock, where a custom replacement locale would be useful. Ah, you say, but you can do that with user overrides, you don't really need a custom locale. Most well behaved applications would respect the override (but that's another post), so that should be enough.
Well, for some locales our "perfectly fine" data isn't actually perfect. Not because we haven't tried really hard to make it perfect, we have, it just might not be perfect for you. Take Norwegian, Nynorsk (Norway) (nn-NO) for example. Looking at our data, apparently the word for "Sunday" is "søndag" (Windows Vista and .Net 2.0). Or maybe its "sundag" (earlier versions).
It so happens that there are apparently two "correct" spellings for søndag in Norwegian. My understanding (which is probably incomplete) is that "søndag" is the "preferred" spelling, but that in some areas "sundag" is preferred because of a Norwegian (Bokmål) influence. I'm told that the preference for one of the other is about 50/50. So, depending on where someone lived and what their expectations were, they may want to replace the built-in locale for one with "sundag" for that day name.
Another example would be the Euro. As more countries adopt the Euro, they'll need their currency symbol (and name) changed. User overrides and the Euro tool can override the currency symbol, but not the name, and those changes can be ignored or undone. A far more effective solution is to create a replacement with the correct symbol and currency names.
This kind of thing happens with all sorts of locales. März can be Maerz in German. Turkey has the New Turkish Lira which might change back to the Turkish Lira once it stops being new. Mexico's New Mexican Peso has become just the Mexican Peso, etc.
It is also important for application developers to realize that these kinds of changes can happen so if the Romanian Leu ever changes to the Euro or an administrator makes a 24 hour clock the default in the US, then hopefully a bunch applications won't break. Previously this could be controlled by ignoring user overrides (not a good idea), but now cultural data is nearly guaranteed to change due to these good reasons, so applications should expect it.
