Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
Almost a month ago I was talking about how GetCurrencyFormat and GetNumberFormat take strings for their number parameters and why. And John Bates commented:
One of my web forms (an invoice) has a column of currency amounts with a total at the bottom. The customer prefers to have the currency symbol only on the total. So I should really be using GetCurrencyFormat for all the numbers, but have to use GetNumberFormat to get a string without the currency symbol. So my question is: Does the number format for any locale differ from its currency format, with the exception of the symbol?
The answer to that question is that there are indeed locales where they are different, indeed that is the reason that all of the settings between the two are kept separate.
The PMs who work with customers and governments and subsidiaries know that the ramifications of adding an LCTYPE to GetLocaleInfo, especially one that will affect other functions and parsing/formatting rules in Windows or the .NET Framework, keep them from ever adding LCTYPEs without having proof that they are needed. It is in fact why sometimes the names do not seem 100% consistent (e.g. there is a LOCALE_SDECIMAL and then there is a LOCALE_SMONDECIMALSEP). The latter was added because it became clear that there are sometimes differences....
And this is an ever-evolving issue. For example, when all of the various percentage formats were added for the .NET Framework, a lot of the data was always identical to the numeric formats, so extra data fields were not added for them. But as data comes in that there are differences in some cases (as it has been), then the decision on what fields to add has to be made....
Sorry, John. You may want to find a better way to get the data....
This post brought to you by "㉧" (U+3267, a.k.a. CIRCLED HANGUL IEUNG)
So as Windows 8 was being developed, we had a huge review done of locale data.
Quite a few bugs were