by Michael S. Kaplan, published on 2007/07/24 01:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/07/23/4021529.aspx
(Apologies to Roger Ebert, whose book I parodied for the sake of this blog post was a wonderful and not just for the great 0 star Deuce Bigalow: European Gigolo review!)
As a by the way, this post does NOT represent anything beyond my own personal recommendations based on the way I think things are going. I am not even on the team that decides these things any more and I wasn't in charge of the strategy when I was then. Anyone who quotes me with prefacing words like "According to Microsoft..." is a complete and utter moron.
Anyway, your LCID sucks.
(This assumes you are still using LCIDs when you could be using locale names, of course!)
How do I know that your LCID sucks?
They all do!
It started back in 2002, when Cathy and I each did one hour presentations for a big group of Microsoft employees about standards and our plans related to them.
Of the whole twenty two slide two hours worth of presentation, one slide I wrote probably got the most email afterward.
It was entitled The Death of LCIDs.
Point after point as to why these things are so awful. From the lack of scalability to the fact that custom locales wouldn't work to their proprietary nature and so on. Not to mention all those problems with Walking off the end of the eighth bit.
And if you'll recall, other people hate them too -- like Bill Poser whose valid criticisms of these things I talked about earlier this month in I think they might kind of get it now.
And then in 2004 when I did a presentation to GIFT about locales whose title was "Intro to Locales (and what's wrong with LCIDs)" that practically had more slides explaining why LCIDs suck than anything else.
LCIDs are just beastly.
It is time to move to names instead of LCIDs. Because going forward who knows how many new features will only exist in the "name based" NLS API functions rather than the LCID based ones (just as has already happened with all of the v.next versioning stuff and custom locales and so on).
Because locale names are based on RFCs that are based on international standards.
Because SAIO would really prefer it that way.
And the ninth bit too!
I'll close with some reworded Smash Mouth lyrics:
Somebody once told me Microsoft's gonna roll me
I ain't the sharpest tool in the shed
The code's looking kind of dumb with its finger and its thumb
In the shape on "L" on its forehead
Well the numbers start coming but will they always keep coming
Don't ignore me now and hit the ground running
Doesn't make sense not to just use names
C'mon you're smart so please don't be lame.
So much to do so much to see
So what's wrong with following the RFC
You'll never know if you don't try
Just tell those LCIDs goodbye.
Hey now, names are All Stars got their game on, go play
Hey now, LCIDs suck so, their so '90's, they'll fade.
And all that glitters is gold
Only locale names break the mold....
Ok, I can't do any more of this. You get the point. :-)
But truly, you should start moving toward using locale names instead of LCIDs. It's time to stop associating with those shady sparsely allocated DWORD kinds of types....
This post brought to you by L (U+004c, a.k.a. LATIN CAPITAL LETTER L)
# Mihai on 24 Jul 2007 1:14 AM:
"Doesn't make sense not to just use names"
"So what's wrong with following the RFC"
Two words: Windows XP!
Just ask Raymond about the value of "backward compatibility" :-)
Yes, LCIDs suck, and named locales are the right thing. About 5-10 years from now, when XP is dead.
# Michael S. Kaplan on 24 Jul 2007 1:48 AM:
Ah, but there are downlevel packages to help with that -- both for NLS and for MUI. :-)
# Michael S. Kaplan on 24 Jul 2007 1:49 AM:
And of course LCIDs remain backward compatible, but that doesn't speak to future features (like versioningm for example).
2011/03/26 An over-complexity worthy of an ISO standard
2009/05/26 The Whey doesn't get a locale, either
2007/09/11 Perhaps they don't quite get it just yet, #1
go to newer or older post, or back to index or month or day