Where the hell did Replacement Locales come from?

Not too long ago, I was talking to a developer who was looking at an issue with Replacement Locales on Windows who pointed out that they simply saw no real purpose for them (the actual language was a bit more raw then that, but it was not terribly original or else I'd quote it here just for color!).

Now I have talked about Replacement Cultures/Replacement Locales in the past (like in this post) and Cathy and I have mentioned them in one of the articles we wrote (this one). It is a subject that both Shawn (e.g. here and here) and Kieran (e.g. here) have talked about as well. I thought it would be nice to give a little bit of historical context behind their creation....

The early, initial checkin of custom cultures (the technology upon which custom locales were later based) did not allow one to override the name of an existing culture -- either a custom one that had already been created or a built-in culture provided by Microsoft. The reason was fairly simple -- the LCID was a read-only property, and no one was excited about getting into the business of allowing custom LCID values, and no one wanted to make new CultureInfo(0x0409) behave differently than new CultureInfo("en-US"). 

Underlying the admittedly simplistic issue was as general unease about the data underlying 0x0409 and "en-US" as well (not to mention all the other locales!), a nervousness about what people might expect in the way of stability of results.

Given all of the different ways that users could customize so many of the culture/locale settings for their selected user locale in Windows, in most cases that unease would be limited to just the items that could not be overridden. But the feeling of unease was a reasonable one, even if it was not rigidly defined (people felt very little pressing need to define it once the decision was not to do it!).

Unfortunately, this made one of the very important problems (one which drove custom cultures and custom locales as a feature) impossible to address -- the need to make easy updates quickly when scenarios came up such as a country moving to use the Euro. If one could no longer ask for a culture by the old name and get the update, then nothing would actually have been updated, in some really important situations.

After some initial suggested limitations came up in an early conversation between Shawn and I, and recognizing the importance of this scenario, some effort was made to go to different groups throughout the company to see what properties of locales and cultures they were making assumptions about.

An unhealthy number of them had assumptions about date/time/number/currency formats, but it was easy to point out how they would already have problems in the case of the user's default locale. However, specific groups like ESENT (Jet Blue) and SQL Server and Office had dependencies on items such as collation support and code pages.

It was somewhat heartening that most of the items came up in that initial conversation I had with Shawn, it was a good indication that we were on the right track with the modification of the feature?

These types of items are never overridable by users within the setting of a particular locale, so it seemed reasonable if a plan was to be formed to freeze those settings and not allow them to be changed. That small set of features and the connection between name and LCID seemed like the best items to freeze if one was trying to replace a built-in culture, even if they were a bit more open in the case of a custom culture that was not trying to override a built in one.

And thus replacement locales were born!

Would these limitations be there forever?

Who knows? Maybe they are a limited-number-of-versions, your locale code is on the roof type limitation to give people time to realize that if they are not allowing for the fact that these settings change that they my have bugs....

Now since that time, when various PMs and testers (and in one case a tester who became a PM) came on board to the NLS team and owned either locales or some area affected by locales, at some point it seemed almost inevitable that they would openly ask what the point of replacement locales was (though unlike the developer I mentioned earlier, PMs are usually a bit more polite in their language!).

It seemed almost one of the developmental stages of dev, PM, and test in this area to question the feature once they understood enough about locales to feel that these particular ones did not seem to fit as neatly into the picture. It was even true of the team that did the work on the Locale Builder, as they were ramping up. Which for me at least made it a happy event as having people understand an area makes their success working in the area so much more likely. :-)

And that is why we have replacement cultures and replacement locales, and why they have the limitations that they do.

This post brought to you by € (U+20ac, a.k.a. EURO SIGN)