Leave it to Microsoft to take the most confusing thing and make it worse!

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

The other day when Tom asked me a question (discussed previously in Sometimes the things that used to be different aren't anymore), he didn't just ask me that one question....

His second question was about something else, though. So putting it in that same blog might have been kind of awkward.

A new blog seemed like a much more reasonable idea. :-)

Tom's following question?

Do all those cultures with LOCALE_ SMONGROUPING set to “3” really actually want it set to “3;0”, but there was just a mistake in understanding how to encode the preference?  (Similar question could probably apply to LOCALE_SGROUPING.)

Hmmmm. More locale stuff.

Let's start with the definitions again. Documentation is our friend, isn't it? I mean, it didn't work out so well last time, but maybe that was a fluke. Take 2:

• LOCALE_SGROUPING: Sizes for each group of digits to the left of the decimal. The maximum number of characters allowed for this string is ten, including a terminating null character. An explicit size is needed for each group, and sizes are separated by semicolons. If the last value is 0, the preceding value is repeated. For example, to group thousands, specify 3;0. Indic locales group the first thousand and then group by hundreds. For example, 12,34,56,789 is represented by 3;2;0. Further examples:
  

  Specification	Resulting string
  3;0	3,000,000,000,000
  3;2;0	30,00,00,00,00,000
  3	3000000000,000
  3;2	30000000,00,000

• LOCALE_SMONGROUPING: Sizes for each group of monetary digits to the left of the decimal. The maximum number of characters allowed for this string is ten, including a terminating null character. An explicit size is needed for each group, and sizes are separated by semicolons. If the last value is 0, the preceding value is repeated. For example, to group thousands, specify 3;0. Indic languages group the first thousand and then group by hundreds. For example 12,34,56,789 is represented by 3;2;0.

Now it is would have been nice if LOCALE_SMONGROUPING could have samples like LOCALE_SGROUPING did. But basically it is all kind of inferred -- one is for numbers in general, and the other is for currency values.

Tom's question is interesting when you consider how easy it can be for someone to misunderstand the format and give the wrong value. One could easily imagine the format being wrong for a given locale if such a mistake is made....

Perhap more instructive is a look at the ones where these two values are different:

All the other locales have the values of these two properties identical.

Now I'll admit to being a little suspicious, of pretty much all of them. But in particular the notion where money is treated differently than other numbers. Though that could be due to my living for so long in a place where they are both the same.

Like much that is in locale data, it is entirely intuitive in you own locale and proof that some people out there are crazy in every other locale!

I haven't been to every locale in the world long enough to check then all out, but I know that some of them are formatted exactly as Windows suggests.And I doubt that is due to Windows being wrong but everyone using Windows.

At least not every time. :-)

In .Net, the attempt to make for something slightly more intuitive can be seen in NumberFormatInfo.NumberGroupSizes and NumberFormatInfo.CurrencyGroupSizes. That didn't turn out so well though.

You see, it has to do with not how they are documented, but how they are implemented (and then documented without the appropriate irony).

First let me take the same table as above and give you the .Net version of it (note that rather than a semicolon delimited string, the property is a one dimensional array):

I assume you can see the difference?

Yes, that is right. While Win32 says:

If the last value is 0, the preceding value is repeated.

While .Net says:

 If the last element of the array is not 0, the remaining digits are grouped based on the last element of the array. If the last element is 0, the remaining digits are not grouped.

Yes, that's right -- the semantics were pretty much reversed.

And to make matters weirder, Microsoft Locale Builder:

uses the .Net rules, yet it uses the native code (semicolon-delimited) format!

So, since both products have the same source now (both in the Microsoft locale data and in custom locales/cultures, the code in one of them has to reverse the information when building the string.

Not that it really matters, but they did technically choose the slower way to store it all -- want to make a wild guess which way that might be? :-)

To get back to Tom's question: I believe most of the values are correct, because over the years small corrections have been made based on bug reports. But the values are confusing enough that it is easy to imagine that any time the person providing the data doesn't look at a sample displaying how the value formats values the results will be wrong, until someone finally reports a bug.

This reversal, and this design, really makes very little sense to me, for what it's worth. I mean except for sentiment in the title: Leave it to Microsoft to take the most confusing thing and make it worse!

I might have to start insisting that Tom provide a beer -- one per question. The rules will vary for others but generally speaking I can't process one of his more interesting edge case questions without wanting a drink. :-)

ErikF on 3 May 2011 12:32 PM:

Emperor XLII on 4 May 2011 7:05 AM:

Michael S. Kaplan on 4 May 2011 7:16 AM:

Bjartur Thorlacius on 4 May 2011 2:11 PM:

referenced by

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