Why Create a Replacement Locale Instead of a New Locale in Vista?

Previously I blogged about the instability of culture data.  Now I'm going to look at the question from the other direction.  Why create a replacement locale/culture instead of a new locale in Vista?  Won't that confuse applications when they cross machines?

To start with we expect locale data in its various forms to reflect human (not machine) preferences.  The primary reason we provide locale data is so that applications can format data appropriately for the regional preferences of the humans using the system.  Applications wanting to exchange data with each other may use standards and formats appropriate for that use.

Another assumption is that the user knows what is "right" for their machine.  Right for them may be a simple format change, correcting erroneous data, conforming to a local change like a new currency symbol, or choosing between spelling dialects for month names.  Right for a user could also be something unusual like spelling all the month names in Pig Latin.  The point is that the user has a reason for making these changes.  It could be because they are just being silly, or there could be an important enterprise wide business decision.  Maybe they just want to test that their applications and tools still work correctly if the month names are twice as long as expected.

The locales on a system are identified by locale name, IETF name or LCID, depending on the application or standard.  Applications could redirect queries for locale information to alternate locales, but that would have to happen on a per-application basis.  Applications unaware of such a technique couldn't take advantage of user corrections.

If the generic locale data is wrong, has changed, or is just not preferable to a user, then fixing that data for all applications has to happen at the level of the locale.  Creating an en-US-Mine won't help much if all your apps still use en-US for their data. 

For new locales having new ids is fine.  If your app gets http-request headers asking for en-FJ and you don't have en-FJ resources on your machine, then falling back to en-US or en might be fine.  Adding a new en-FJ custom locale might be better though, assuming that your app has enough traffic to justify the customization. 

If those http-request headers are asking for en-US however, adding en-US-Mine won't help.  The request for en-US would continue to get en-US instead of the customized en-US locale.

As mentioned in my previous post applications need to be aware that the data can change and make sure they behave appropriately when it does change.

I've seen apps that were written expecting one locale and start failing just because they're installed in a different country.  I've seen apps try to exchange data between different locales and fail because the number thousands and decimal changed from "." and "," to "," and ".".  I've seen apps fail because new locales were created with longer strings than any of the old locales had.  They've also failed because the OS was upgraded and some preference changed.

These things usually happen not because someone did something unexpected, illogical or "illegal", but rather because the application hadn't considered the impact of different locale data.  The data we ship is but a small subset of the world's locale data.  Most of that will probably be reflected in new locales rather than changing locales, but sometimes users will change an existing locale.

Perhaps your app behaves fine so long as its running with an en-US locale.  That probably covers most of the US and maybe your app's restricted to the US market.  Some people might have experiences that make them prefer a 24 hour clock or a d/M/y format, but your app can avoid that by ignoring the user's preferences (not a good idea, user's get grumpy when their computer ignores their desires.)

Even then, will your app still run when they change to es-US (Spanish US)?  We're shipping es-US in Windows Vista.  Suddenly that US market will have machines with a Spanish locale.  What happens if they decide to make a custom locale for other languages in the US.  Ethnologue reports 162 "living" languages in the US.  Presumably custom locales could happen for a lot of those.  If your app can handle all of those, its shouldn't do too bad when someone replaces their en-US locale.

P.S.  If I ran a server farm or something where the machines really required the same behavior, then in addition to making sure that they were running the same OS and Service Packs, I'd make sure that any locale customization was done equally as well.

Comments (1)

  1. Not too long ago, I was talking to a developer who was looking at an issue with Replacement Locales on

Skip to main content