by Michael S. Kaplan, published on 2009/08/20 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/08/20/9876922.aspx
This blog is not about the economy!
Regular readers may remember this blog, where I mentioned how much I limited my negative categorizations -- the whole English language and I was holding it down to three adjectives.
It turns out that there is a part of Microsoft that has even less variability in its expression of negatives! :-)
Over in the Suggestion Box, Johannes Rössel asked:
Hello,
I am currently trying the Windows 7 Beta and decided to play around a little with the Regional and Language Options. So I set the negative sign symbol for numbers to U+2212 MINUS SIGN, instead of U+002D HYPHEN-MINUS. I just wanted to try how far I would get with that until I see misbehaving software.
So far, so good, I headed over to the Currency tab where you can select a negative currency format. However, neither the sign use for negative currencies is customizable, nor is the sign set in the numbers tab used. It always shows U+002D (except for the variants where the number is simply put into parentheses.
Is that kind of unlinking number and currency formats intentional? If so, why exactly? Is there a locale where the number negativity sign is different from that for currency?
Regards,
Johannes
This question delves into many of the interesting issues that drive the nature of choices in locale data.
The behavior in question is one you can see in pretty much any version of Windows; it is not specific to Windows 7....
Sure enough there is a LOCALE_SNEGATIVESIGN one can set in SetLocaleInfo but there is no negative sign for currency values. And what is worse is that like Johannes indicated, LOCALE_SNEGATIVESIGN doesn't change the negative sign used in formatting currency values.
If you look at locale data at more of a macro level, much of the data that can be set really owes its presence to the fact that some locale expected a particular kind of behavior. It is usually not developers who find bugs, it is instead either end users who notice things in Regional and Language Options, or the stakeholders providing data for a new locale who note something thast they do not seem to be able to specify.
This feedback drives limitations on what can be set (for an example I have talked about before see When the roof got raised, and why) and also what data is available to be set.
In theory developers have mush more exposure since they can look at any data, though in practice bugs are found by regular users finding problems in data that is directly exposed (bugs in the data not as visible to users can stay unfixed for years since the problem can be unknown for so long!).
Now this case in particular, I cannot imagine that there is a situation where any locale actually expects a negative sign for regular numbers but not currency values -- I certainly don't know of one. Thus my initiasl assumption would be that the problem is mostly an oversight.
Though since it is so long-standing a serious inquiry would be required for all locales to make sure such an initial assumption is true (similar assumptions in the past about the decimal separator in number and currency values have proven to be false).
It is almost something I could imagine having linguistic consequences since we are talking about formatting and in a way grammar. Though I don't know to what extent people might object to results in specific locales.
The consequences for changes here to anyone who has made the effort in parsing/formatting would also need to be considered, as that scenario is the one case where developers do sometimes report bugs: when they get unexpected data in their algorithms and assume the unexpected result is a bug. In this case, no developer has done so, but it is hard to guess who might have noticed this discontinuity and worked around it already (in a way that fixing the problem might break).
I'll be honest and say the one thing I miss the most about the time period I was involved in locale data (what I like to think of as the silver age of locale data) is the conversations about what should be done to handle problems like this. In fact I am having lunch later today with one of my comrades from those days and will likely mention this issue while I'm there!
But I will also be honest and say that even though I loved discussing and working through the issues on such bugs, I seldom enjoyed the final decisions in such cases since they can always potentially lead to negative consequences for users (end users or developers, or maybe both!).
I should probably explain the whole silver age thing further, but that can wait for some future blog, probably. :-)
achat pc on 11 Sep 2009 11:16 PM:
Exactly I agree with you that it is the regular users that find bugs as they encounter problems. Developers only find it when they get unexpected data in their algorithms and assume the unexpected result is a bug.