Get Number Format () was 25 years late
December 28, 2005Don’t get me wrong: As a self-appointed i18n specialist, I consider locale-aware APIs (such as GetDateFormat(), GetNumberFormat() et al) blessings to make your apps world-ready by respecting your users’ culture. It’s not a question of politeness or education. It’s just plain necessary if you want users to understand what your program display.
What d’you mean 9/23 ? There ain’t no 23 months !?
Let’s take dates for example: Take it the way you want but if you tell me 8/9, I’ll understand Sep 8th. Don’t expect me to think Aug 9th because I don’t even know that somebody, somewhere, might read it Aug 9th ! And if you tell me 9/23, I’ll tell you you read too much sci-fi about time machines. That’s why using GetDateFormat() (or any of its higher level wrappers) is so important.
Regarding numbers, GetNumberFormat() and his sister GetCurrencyFormat() helps you make sure ten thousands is written 10.000,00 for most Europeans and 10,000.00 for Americans (and whatever format is used for each other culture).
Computers were babies, and babies don’t study languages
Yes, we Europeans use a comma as a fractional separator. That’s what we learn in elementary school. That’s how we write numbers. We don’t even think of doing it another way !
Errrr… Really ? Well, there is a catch : When the first “pocket” calculators appeared in the late 60’s or early 70’s, and when the grocer around the corner started to use a machine to print price tags, instead of writing them down, we started to set our minds: Printed numbers use a dot to indicate the fractions (we’re not used to commas as thousands separator though) because the calculator was manufactered by an American company and so was the labelling machine used by the grocer… And these machines didn’t have GetNumberFormat(), unfortunately !
The interesting point is that we learned that printed numbers use a dot. But we didn’t change the way we write. And we inconsciously make a difference between handwritten numbers and printed numbers ! Since machines didn’t speak our language, we learned theirs. But it doesn’t mean we forgot ours.
By the time the kid grew up and studied languages, it was too late
Then came GetNumberFormat() and Excel starts using commas for fractions. WTF ! Nobody prints numbers that way ! It’s just plain ununderstable. Pleaaase, get me rid of this comma and replace it by a good old decimal point… Thank you.
OK. Everybody happy again. But still, officially, Belgians use decimal commas. So when our IRS published its web-based tax declaration system 2 or 3 years ago, they followed the official rules and uses. I remember I filled the whole lot of fields in the huge form and clicked Next.
Please fill in with numbers. Beg your pardon ?? It took me 10 minutes and several tries to realize the problem was with my decimal points. The form wanted decimal commas ! Plain unusable !It didn’t last: The next year, one could use decimal points…
The problem is that programs display so many numbers : We, the devs, just can’t use GetNumberFormat() each time. And since people are used to it (people don’t even think of printed numbers looking like written numbers !). If at least the CRT and other major libraries used it (After all, these libraries do use GetDateFormat()…), we would get correct display of numbers for free and the format would become ubiquitous. But for some reason, the CRT doesn’t use locale-awre APIs to format numbers (I guess there are reasons. I’ll ask my good friendMichael).
The net effect is that using GetNumberFormat() can become counter-effective, according to the context. And it’s pretty hard to know if the context is good or bad 🙁
“And Excel ?”, you ask
Well, It looks like the Office team didn’t want to break the whole work done by their colleagues at the i18n team : If I type the dot in the digits pad, Excel writes a comma (!) and considers it a decimal separator. Pretty weird at first, but you know what: We now get used to reading printed numbers with commas… as long as it’s in Excel !