The evolving Story of Locale Support, part 10: Perhaps it is best to think of it as unintelligent design?

by Michael S. Kaplan, published on 2011/11/22 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/11/22/10239572.aspx


Previous blogs from this series:

Now I'm much bigger fan of evolution than intelligent design.

Though as opposites go, they are a bit unbalanced.

Design can be carefully planned yet be quite unintelligent, after all -- that is in fact lore provable.

So here in this series that talks about the EVOLVING story of locale support, I thought I'd give such an example, in order to help out a colleague!

Now in part 9, I took the following list that applied to all the prior parts:

  1. They are all features of Windows 8 (and.Net 4.5, where applicable), and
  2. They are all things that I think are really cool, and
  3. They have all been a long time coming, and
  4. I have been intimately involved with every of them.

Then in part 9 I found one where only the first three applied.

Now I'm going to point out something that none of them really apply to, but which nevertheless talks about the evolution of locale support at Microsoft....

It started when we added a locale for "English - Caribbean" (LCID value of 0x2409).

We already had several locales that conceivably fit under that grouping:

Locale LCID
English - Jamaica 0x2009
English - Trinidad 0x2c09
English - Belize 0x2809

One could think of "English - Caribbean" as being an easy way to avoid having even more people ask for locales for the Cayman Islands and Barbados and Antigua and so on and so on.

And in the world where everything was based on LCIDs, that was fine and dandy.

But as we became more and more of the opinion that LCIDs suck, we at first for the sake of .Net used the "name" of en-CB until we rather embarrassingly realized how unintelligent we had been here -- what's the point of moving to a less proprietary solution to a more standards based one if we just start making up codes?

Thus, as I discussed in The road to standards compat is paved with app back-INcompat, we changed it to the ISO 3166 region code: en-029.

Perhaps this points to the solution to the issue raised by former colleague Sébastien Molines in the Suggestion Box:

Hi Michael

I've read recently about es-419, or "Spanish appropriate to the UN-defined Latin America and Caribbean region" -- See http://www.inter-locale.com/ID/rfc5646.html#region

Such a language code would be really useful for the company where I work, which specifically targets the South American and Caribbean markets rather than Spain. But it seems that the .NET Framework doesn't support region subtags. Do you think it's something that will be supported some day? If not or in the meantime, what's the best way of supporting South American/Caribbean locales and in particular localizing for these markets in one go?

Hope all is good--I have good memories of working with you!

Seb

Now whether or not Microsoft ever wanted to add es-419, the fact that we added en-029 sets a clear precedent that could be used in any company's strategy for custom locales/custom cultures

Sébastien's company could thus create an es-419 custom locale, though he may run into the big problem that our en-029 had -- that the date formats and currency preferences and even the dialect can vary between the Cayman Islands and Barbados and Antigua and Saint Vincent and the Virgin Islands and all of the other places where Caribbean English is spoken.

This points out the downside of such groupings -- it is hard to give consistent and correct data for them!

Perhaps it would have made more sense to create en-BB for Barbados, en-JM for Jamaica, en-AG for Antigua, and so on. :-)


comments not archived

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2012/10/26 The evolving Story of Locale Support, part 28: We finally fixed that 'Install New Languages' thing!

2012/10/02 The evolving Story of Locale Support, part 27: No, the T and the H aren't silent...

2012/08/20 The evolving Story of Locale Support, part 26: Hey Windows 8, there's someone on the phone for you.

2012/07/11 The evolving Story of Locale Support, part 25: Something old, something new, something repurposed, and something...

2012/06/07 The evolving Story of Locale Support, part 24: I Adar you! Hell, I Double Adar you! (Windows 8 ed.)

2012/06/05 The evolving Story of Locale Support, part 23: Tamazight? Outta sight!

2012/04/12 The evolving Story of Locale Support, part 22: Digit Substitution 2.0

2012/03/08 The evolving Story of Locale Support, part 21: The Windows 8 Hijripalooza extraordinaire!

2012/03/02 The evolving Story of Locale Support, part 20: Yes, it's Bangla. Not Bengali!

2012/02/21 The evolving Story of Locale Support, part 19: In honor of International Mother Language Day...

2012/02/15 The evolving Story of Locale Support, part 18: Two scripts that share ten digits can be trouble

2012/02/02 The evolving Story of Locale Support, part 17: Today I feel like translating you more than before

2012/01/24 The evolving Story of Locale Support, part 16: We can't scale to a Xishuangbanna Dai locale, but…

2012/01/17 The evolving Story of Locale Support, part 15: Fixing our listings up in Windows 8!

2011/12/22 The evolving Story of Locale Support, part 14: Tifinagh, Tamazight, and Berber? Oh my!

2011/12/21 The evolving Story of Locale Support, part 13: Divvying up locales, yet again!

2011/12/09 The evolving Story of Locale Support, part 12: Logic dictates that we keep a sense of proportion about the RATIO

2011/11/23 The evolving Story of Locale Support, part 11: What language is that keyboard for?

go to newer or older post, or back to index or month or day