by Michael S. Kaplan, published on 2012/09/24 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/09/24/10352537.aspx
So as Windows 8 was being developed, we had a huge review done of locale data.
Quite a few bugs were fixed during that process.
And we learned some very interesting issues, as well!
Like if you look back at a blog I wrote back in 2005 (Number format and currency format are not always the same), I didn't give the actual example I had in mind -- the fact that we have separate LOCALE_SDECIMAL and LOCALE_SMONDECIMALSEP settings -- because that example wasn't in my mind a very good one.
Because we had data that said the decimal separator for Farsi (Persian) was U+002e (aka FULL STOP), while the currency decimal separator for Farsi (Persian) was U+002f (aka SOLIDUS). But since it had been over a century that the IRANIAN RIAL had ever needed to be divided into fractional values (often known as DINARs).
They didn't even make the coins any more, so it seemed like a stretch to speak about such a theoretical issue.
Geeks such as myself are often proud of our arcane knowledge, but often try to avoid calling attention to it when it makes us seem silly!
This didn't stop us from voting in favor of changes suggested by Asmus Freytag to the Unicode Bidi Algorithm (UAX #9) to make it more "Microsoft-like) back in early 90s, by changing the Bidi class of U+200f (aka SOLIDUS) to make sure numbers on either side if it were not flipped/reversed, since we figured that was what we were doing anyway. Why not be happy if a standard changes in a way that makes us more conformant? :-)
But one of the review feedback items that surprised us was how much more likely we were told that the LOCALE_SDECIMAL value was often expected for Persian (Farsi) to also be U+002f (aka SOLIDUS).
Thus the whole original reason for having separate LOCALE_SDECIMAL and LOCALE_SMONDECIMALSEP values was perhaps not as true as we had thought!
But obviously we couldn't remove a constant that had been around/documented/change-able since Windows 95, so we just changed the one setting -- the LOCALE_SMONDECIMALSEP for Persian (Farsi), and left it at that.
Good thing we didn't fight those Unicode changes almost a decade ago for a theoretical currency formatting/parsing issue, since it seemed to also be a not-so-theoretical number formatting/parsing issue, too!
And then the wheels started to comer off the wagon.
Because it looks like Unicode may have also changed things back, too.
And because even though Uniscribe/DWrite/Access/Excel handled the <NUMBER>/<NUMBER> issue "properly" -- in other words the same as <NUMBER>.<NUMBER> -- it turns out that Word/One Note/Internet Explorer did not!
So the Windows 8 data change has now been reported as the cause of an Office regression.
As has Office's own inconsistent behavior!
The fact that those same apps are not comformant to wider Microsoft -- or perhaps even Unicode? -- behavior for currency values for almost as long as Win32 has been around is now something that has to be carefully considered as a potential "should we revert the platform" issue, instead of a bug in the apps!
Oops!
We'll need to take another look at this issue (I'll fold in any feedback people give here to that discussion when/if it happens).
And we'll have to never forget that not every part of Microsoft does things the same way!
PP on 26 Sep 2012 6:21 AM:
Hello Michael, Is there (or will be) any full documentation about I18N in W8, especially changes in locale data, fixed bugs, new localized UI's etc ? It would be very useful.
Cheers, Pawel.