Yet another time they messed up. Respectfully.

by Michael S. Kaplan, published on 2011/10/21 07:01 -04:00, original URI:

So, the movement fromLCIDs to names continues apace (ref Your LCID sucks and It is true that your LCID sucks, but your LANGID sucks more).

Of course not everyone looks at LCIDs the same way.

Thus Decimal vs. hexadecimal LCIDs, backcompat, and being weird, for example.

Now I know Office and DevDiv and SQL Server tend to use decimal values for LCIDs and LANGIDs.

Which I do not.

And ordinarily I am not judgmental about alternate world views.

Again, I'm not.

Though in this case I think they are definitely wrong.

I realized just a few days ago when Murray told me that over in Office they had to change the size of some data structures that they were storing LCIDs as strings.

Because they were going off the end of the four character buffer they were using to store them in with some of the bigger LANGID values.

If they were just using hexadecimal digits than the buffer would have been enough.


On the other hand, they could have stored them as numbers and it al would have just worked irregardless. :-)

John Cowan on 21 Oct 2011 7:55 AM:

There are still a frightening number of people and even standards who believe that language tags are exactly five characters long, like "en-US".

Michael S. Kaplan on 21 Oct 2011 8:46 AM:

ca-ES-Valencia?  Nuff said! :-)

Doug Ewell on 24 Oct 2011 3:05 PM:

Don't ever say "irregardless."  Not unless you really mean "WITH regard to."

Michael S. Kaplan on 25 Oct 2011 7:06 AM:

I love to say irregardless -- it brings out the language maven in the best of us!

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.

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