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:

• part 9: Nastaleeq vs. Nastaliq? Either way, Windows 8 has got it!
• part 8: [Finally] taking care of some [more] languages in Pakistan
• part 7: That would be a "call and a raise" for Hawaiian
• part 6 (Behind the Cherokee Phonetic layout in Windows 8)
• part 5 (...until the decision was made to not refuse to add it)
• part 4 (working beyond one's bugs, and the case for an MSKLC update)
• part 3 (working beyond one's bugs, the setup)
• part 2 (raising the roof on keyboards)
• part 1 (Some people don't want to double-d's)
• part 0 (The introduction)

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:

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. :-)

referenced by

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