isn't number localization just unnecessary?

Question

I've just read this page http://weblogs.asp.net/scottgu/archive/2010/06/10/jquery-globalization-plugin-from-microsoft.aspx

One of the things they did was to convert the arabic date to the arabic calendar. I'm wondering if it is a good idea at all to do so. Will it actually be annoying/confusing for the user (even if the user is Arabic).

Also, my second question is that do we really need to change 33,899.99 to 33.899,99 for some cultures like German? I mean it doesn't hurt to do so since the library already does it for us but wouldn't this actually cause more confusion to the user (even if he is German, etc).

I'm sure whatever culture these people come from, if i give you a number 33,899.99 there's no way you'd get that wrong right? (unless my website/application is the first website/application you've ever used in your entire life, which arguably is possible but the probability is just that low)

I meant "universal" as the format that everyone will see and know what it means. It doesn't have to be some standard written in black-and-white and the like. As long as everyone can read it and know straightaway without confusion what the text is representing, that's universal. To be sure, 1.234,00 is definitely not universal. I mean i'm very sure you can find someone who in their entire lifetime, has been using computers yet have never came across this number format at all. Since most websites/apps had been using 1,234.00 without changes to accommodate localization, I believe that it has been the de-facto (the universal format that everyone will see and know what it means).

As for dates, if we write 01/02/03 I'm sure there's no way anyone will know (straightaway, rightaway, without ambiguity) what date it is. But no one can get Jan 2 2003, Feb 1 2003, Feb 3 2001 wrong if we wrote them as such isn't it?

Btw this question is targeting localization, don't tell me stuff like "Hey not everyone reads English alright!" because that is a matter of internationalization (which is beyond this topic). Let's stick to the discussion on localization.

Answer 1

Why should non-Anglos have to decode dates, numbers, etc. while Anglos can just read them? Numerical and date localization is absolutely necessary if you want non-Anglos to feel, you know, welcome as users and customers. Why should a German user have to work out what your number is instead of, you know, getting it in his or her own language's format?

Further, your view of number formats (and dates: q.v. below) is hopelessly simplistic. For example undoubtedly you'd find numbers like 1,234,567 "natural" and "obvious" and "logical" ... but what about people who come from cultures with myriad-based numbering schemes? My students (Chinese), for example, are always confused about numbers over 1000 because they group numbers differently. A more "natural" grouping for their thought processes (which include a myriad above the thousand point) is 123,4567. Further there are many contexts in which the European number systems in general are simply not suited. It would be nice in those circumstances to be able to write the all-Chinese 一百二十三万四千五百六十七 or even various hybrid systems that are in common use here.

Your idea for dates is wrong-headed too. You've correctly pointed out how 01/02/03 is ambiguous (if only because Americans refuse to comply with standards on dates) and suggest instead that Feb 3 2001 is unambiguous. I'm not sure, however, if you've noticed something there. It's unambiguous and unambiguously English. Going back to my students, I'm pretty damned certain that they'd far prefer to see 2001年2月3日 (or even 二〇〇一年二月三日) which is both unambiguous and, get this, something they can read without having to decode.

The bottom line on i18n and l10n: Do you want money and/or users? You make what your users want. Your users want things in their own language, not in yours. End of story.

---

edited to add

It gets even worse than myriad-based systems. Take a look at Indian numbering for this lovely progression:

1
10
100
1000
10,000
1,00,000
10,00,000
1,00,00,000

...and so on up to:

100,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,000

See that grouping by three at the end? See that grouping by two after the grouping by three? See the sudden reintroduction of a group by three again?

---

further edited to add (I just can't keep off this subject it seems!)

Even the assumption of decimal number systems being universal is wrong. There are native numbering systems that are 4-based, 5-based, 8-base (octal), 10-based (decimal), 12-based, 20-based and even 60-based. These are all systems which have been in active use by real people (as in not made up for science fiction stories). Not all of these are still living (although we can see, for example, vestiges of 12-, 60-based numerical systems in English terminology).

As for dates, let us not forget the lunar calendars still in active use in much of the world. The Muslim world tends to use a lunar calendar where the dates can drift throughout the whole year while the Chinese use one with a complicated system that keeps the dates never more than a month away from true. (And that's just naming two off the top of my head.)

Answer 2

Also, my second question is that do we really need to change 3,899.99 to 3.899,99 for some cultures like German? I mean it doesn't hurt to do so since the library already does it for us but wouldn't this actually cause more confusion to the user (even if he is German).

Even if the user is German, he'll be confused with German notation? I'm pretty certain I don't agree with that. No, what would cause more confusion to users is the peppering of their localised sites with non-localised data. Numbers and dates are a key issue in this respect.

If you're localising a service, you need to localise it properly. Skimping on number format is lazy and ignorant.

3,899.99 is not the universal format - and the assumption that "everyone will just understand it" is intellectually lazy. It's also comparatively rude. You have the facility to do - since we're discussion a particular link you posted - so why not just do it and show some cultural awareness at least?

Answer 3

American <> Universal.

Reading a date like "Jan 2 2003" takes some time to decode. We always put the day before the month. So it would have to be "2 Jan 2003". Sure we get it but we have to think 5 seconds to decode it.

Show a number like 1,234 and most Europeans will be thinking of a decimal number. 1,345.00 just "feels wrong".

It's OK if you don't localize your app. Just don't expect it to be a hit outside of your country.

Answer 4

Your problem here seems to be a bad assumption. There is no "universal format" for numbers or dates. 3,899.99 is valid in some places, and confusing in others. Same for the converse. People can frequently figure out what they need to, but that's not the point. The same goes for the date formats you talk about. The formats themselves are distinct between locales. There is no "universal" here.

Except in certain scientific and technical domains that general software doesn't usually address, there's no universal format for any of these things. If you want your software to be accepted on native terms anywhere but your own place, you'll need to work for it.

Can you shove some notion of a defacto standard down people's throats? Sure. But localization of numbers (per your question) could never be considered unnecessary in any professional, internationalized software.

Answer 5

You seem to assume that what you are used to read is universal, while it is not.

Where I live, comma denotes the decimal separator, and a dot is used (sparingly) as thousands separator. It is unnatural for me to parse $3,004.25. But if you give me $5,535 I'd probably read it as about 5 dollars and a half. Reading 3.899,99 would not be confusing at all to me, and I just can't see why you think so.

For dates, I can certainly read Feb 3 2001, as well as you can read 3 feb 2001.

So, users can usually parse most numbers and dates localized in us-en. Sometimes there can be ambiguity, like in $5,535. In any case I just don't get why you think that it would be more clear than their own locale.

Answer 6

I don't have much knowledge on number and currency localisation, but dates are covered by ISO 8601 (http://en.wikipedia.org/wiki/ISO_8601) in the format YYYY-MM-DD e.g. 2011-05-10 for 10th May.

Answer 7

Also, my second question is that do we really need to change 3,899.99 to 3.899,99 for some cultures like German? I mean it doesn't hurt to do so since the library already does it for us but wouldn't this actually cause more confusion to the user (even if he is German).

I am German, and speaking personally for me, it is indeed confusing, because I read so many English texts and than German texts again and all mixed together. That's why I have to do a little break on each number I encounter to figure out, what notation rule it adheres to and what magnitude it actually means.

In my localization settings I have therefore configured the digit grouping character to be a single quote ('), as in 1'234.00, which is the system used in Switzerland.

I'm sure whatever culture these people come from, if i give you a number 3,899.99 there's no way you'd get that wrong right? (since he'd probably learned the universal format anyway)

You can probably figure it out, but it takes some time.

I meant "universal" as the format that everyone will see and know what it means. To be sure 1.234,00 is definitely not universal. I mean i'm very sure you can find someone who have never seen this number format in all their lifes. since most apps had been using 1,234.00 without localization i believed that it has been the de-facto (the universal format that everyone will see and know what it means).

You can definitely find a lot of people here in Germany who have never seen the 1,234.00 notation.

Also, there are legal implications in this matter. Imagine a bank account balance written with the wrong decimal point. All sorts of trouble can arise from that.

As for dates, if we write 01/02/03 I'm sure there's no way anyone will know what date it is.

Yeah, I hate that! And so many people still do that, leaving me puzzled each time what date is meant, even more so as there's apparently a conflict between British and American notation, where one of them writes the day before the month and the other the month before the day.

If localization is not possible (like in a written text), I recommend the standardized format 2003-02-01 for anything that might potentially cross your national borders. While you can't immediately see, if Feb 01 or Jan 02 is meant, this notation is standardized to have the more weighty numbers first (month before day).

Answer 8

There are ways to achieve what you want, but they all involve using formats that are natural to no-one. for example, we store timestamps in our product in human-readable format: YYYYMMDDHHMMSS. There's no confusion there, but no-one uses that format in their daily lives.

What I think you're needing is an underlying format that is universal, say, seconds since 1st Jan 1970. Once you have that, you can display the time in any format you like, and libraries and OSes can re-display the correct time any way you like.

Answer 9

More a comment than an answer I guess, but...

It Doesn't Come Naturally

"since he'd probably learned the universal format anyway"

Pardon me, but I didn't really "learn" that "universal" format until fairly late at school, because that's the thing: no one cares. Or at least, until they need to (e.g. for official documents, for business, etc...). So it is confusing when you see formats that do not use the conventions of your culture. The usual MM/DD/YYYY or DD/MM/YYYY is probably a big issue as well.

Learning is a Privilege

Also, quite a lot of people don't get the chance to "learn" those things, unfortunately. Not everybopdy gets to go to school (even primary school) or finish it, even in developed countries. And I cannot stress this enough but: we design software for them as well.

Look the way Google do it. They apparently try really hard to work on language-related products internally, and they also try their best to provide localized services, for this very reason.

While a lot of us here, programmers, do usually prefer our "common" language (English, and encoded in ASCII, pretty please), a great many people feel more welcome when they are greeted in their own language. Like stepping out of the gate in a foreign airport where no one speaks your language and the writing is very remote to yours. It can be a bit scary, if you're not used to it. And to be honest and bring it back to the IT world, even opening a source file containing unicode characters or a phonetically-approximate version of a word from another language is quite distressing.

I do get your premise on the confusion though: you end up wondering every time what the system designer's intent was and what format they aim for. But It's not nearly as confusing for you when that happens as it is for someone who won't be able to understand other things.

Culture Matters

Finally, I think there's another thing at the core of the problem here: if we were to follow your suggestions, then we would cannibalize a lot of other great cultures, which all deserve to exist, be remembered and celebrated. And they live through their writings and these tiny - seemingly irrelevant - details as well: they are part of the cultures, and they exist in each culture for a reason.

I don't want to turn this into a tirade on the expansion of the big mean evil western empire, but it's the sort of things that does trigger people's harsh reactions and comments. Simply because it seems like you want to discard other people's opinions, tastes and cultures (I'm sure you don't) and even suggest that you know better than them what they should use and prefer. Or, in any case, that you have little respect for their ways and don't consider them part of your userbase, don't want to make an effort to welcome them, and don't really care much for them in general.

---

EDIT - Personal Anecdote: my partner yells at me everytime time I write "apologize" or "authorization" with an American spelling instead of the British/Australian spelling, so guess what she'd do to me if I'd start using dates and numbers in a funny way... :)

Answer 10

Most of the World uses , as decimal separator (green on image below). I don't see why majority should adapt to minority.

Answer 11

I think I saw a proposed alternative format for thousands separator: 1'000'000
Although I don't know if there's a proposed decimal separator.
I don't think localization is unnecessary right now.

Usually all of us programmers, and people who wander often in the internet are very likely to be aware of english number format and measures, bur there are lots of people who don't know that much and yet use computers, and can get confused if they see a format that looks like their own, but means the opposite.

I do think that a unification of numbering and measuring standards would be a good thing to do at a global scale, in which 1,000.00 format could be used as standard, why not, but we should definitely loose inches and pounds, and call 1,000,000,000 a billion.

PS: I watch a lot of american documentaries in Discovery and history channel, and they always give measures with football fields as a unit. Do they realize that no one outside USA has a clue about how long an (american) football field is?

Answer 12

My personal belief is

Software localization is harmful

Not only is it poorly executed most of the time, but also it cuts of users from the English speaking community, which has far more resources to get help. This might not be such a big deal for German, but if you take Slovak for example, it's more like shooting your users in the foot, even assuming you get a decent translation. You have to know the local terminology and if it is not suitable to express what you want, you will need to extend it (which risks causing havoc, because somebody else might choose just another term for the same thing at about the same time, or might give the same term a different meaning).
I once had to fix something on a French Mac. It was a pain, because my French IT terminology was worse than that of the owner of said Mac. I had to translate back and forth between guesses of corresponding terminology.

I am quite certain, it is not significantly harder to pick up English terminology, than the native one, and learning English to a degree where you can operate a computer is not much of a challenge. Also it opens up a world to you. Instead, as of now, many software vendors make it increasingly hard to obtain an English version of their software, if you're from Germany, and even worse, many sites automatically pick your language. Microsoft goes so far, that if you google something in English and you open a result on their site, the resource is automatically shown to you in your locale. ARGGH!!!

IMHO, if an interface requires localization to be understood, you got the interface wrong and the flaws won't go away if you translate it, they rather multiply.

Software localization must be done right

If you localize software, there's absolutely no point in doing it, if you don't try to get it right. There's little value in a German interface a German can barely understand.

You agree, that in course of translation, you would translate "house" to "Haus" even though about everybody in Germany would understand the meaning of the former.
Likewise, you should translate 9/11/2001 to 11.9.2001. A German would very likely figure out, that the former notation represents a date, but would probably interpret it as as the 9th day of November 2001.

The reason why I picked just this historical date is to illustrate something with my personal experience. German media sometimes referred to the tragedy as "nine eleven". My English was not very good at that time, especially not my knowledge about date notation, so I visualized this in my head as "911" and figured this was some sort of metaphor using the phone number to associate the event with the feeling of emergency. Looking back at my train of thoughts, I agree it is extremely far fetched, but for someone used to a different date notation it did seem plausible, because it didn't ring a bell, as "eleven nine" would have. This should show you, how engraved certain conventions are in our thinking and how this can lead to misinterpretation of obvious data.

As for numbers, this is not such a big problem for humans, but a far bigger problem for programs. German localized software will output 1234.56 as "1.234,56" (or "1234,56" if you're lucky, or "1'234,56" if you're not lucky at all). If you directly feed that to a forgiving parser assuming English format, it will be interpreted as 1.234 and an unforgiving one will choke on the comma. This is about the same problem, the other way around.
It is also important to note, that on the numpad German keyboard layout, there's a comma, where you have a dot. So you are likely to get German format input from Germans. Being able to handle this is way more important than translating "Cancel" to "Abbrechen".

So if you really head down the "I don't care for formats"-road, do you and your users a favor by not translating anything, because that will at least alert them of an English context. You inflict less damage by forcing people to use a dictionary for words they don't understand, than by printing out information they misinterpret, because they have a different understanding of its meaning than you.