Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
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:
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:
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!
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. :-)
Previous blogs from this series:
part 25 (Something old, something new, something repurposed, and
part 26 (Hey Windows 8, there's someone on the phone for you.
part 27 (No, the T and the H aren't silent...)
part 26 (Hey