4

Historically, I know that in most parts of the world decimals have been represented with a comma.

  • 3.14 (US and Canada mostly)
  • 3,14 (most other places)

In software development, normally a period (3.14) is used. This is true throughout the world. Programming languages provide facilities to display numbers in the UI with the right format, per the user's locale settings.

However, I don't recall ever seeing code that recognizes a comma decimal in input. If a user types 3,14 it's typically either rejected or interpreted as "three hundred and fourteen".

Should software attempt to interpret input such as 3,14 correctly? Or is it not necessary -- perhaps because users are accustomed to adopting "computer" conventions?

  • The culture setting in most programming environment handles both display and parse. It this a programming question or a UX question? – paparazzo Mar 3 '15 at 19:13
4

Good question, but the Wolfram reference is terribly incorrect.

The use of the period . in user interfaces is almost universal nowadays, and I would advise against trying to overload the comma.

The spread of the decimal point is a pretty interesting case on the effects of globalization and technology. In this case, the broad standardization of global financial statements on the decimal point (because commas are used in financial statements to denote thousands, millions, etc) combined with the promulgation of tech user interfaces using decimal points (e.g. mobile phone calculator) has pretty much eradicated the use of commas as decimal separators in user interfaces.

I've been doing business in Europe, Asia and Australia for decades and I have never seen the comma used as a decimal separator in any user interface.

Trying to restore support for the comma as a decimal separator not only bucks a sensible UI trend, but also (and this is IMO) reverses an informal standardization process that has been beneficial for the global community.

On a related note, for financial and scientific applications it's good UI practice to recognize commas and exponents (e.g. 299,792,456 or 3e8) as valid numerical inputs (e.g. when pasted into a calculator or spreadsheet).

  • Thanks a ton, this is exactly what I wanted to know. My understanding was off by a mile. Glad to hear the world is inching toward standardization. – Patrick McElhaney Mar 3 '15 at 19:33
  • 1
    @PatrickMcElhaney I don't think it was your understanding. It seems you did the right research but what should be an authoritative source (Wolfram) was way outdated! I do remember that their old Mathematica software in the 80's allowed commas to be used via user settings. Maybe their documentation dates back to that decade! – tohster Mar 3 '15 at 19:41
  • 1
    Either way, this is a great answer. I owe you a pint. – Patrick McElhaney Mar 3 '15 at 19:49
  • Here is UI that uses comma as a decimal separator out of the box: imgur.com/5VthbLW It's a localized Excel, for Finnish. Numbers with dots are treated as text. Strangely though, calculator understands both dot and comma as decimal separator. – locationunknown Mar 4 '15 at 8:09
  • 3
    I come from europe (rather than just doing business with it), so I don't know how you got this idea that no user interface uses a comma as a decimal separator. Every properly localized application does that. Also wikipedia pretty much confirms what wolfram says. If you don't attempt to localize your application by all means stick with the dot though. Don't make it ambiguous by interpreting comma and dot as the same thing. – David Ongaro Apr 8 '15 at 18:46
3

Ok, I try to provide an answer in hope that it will encourage an expert to jump in, in case I tell nonsense.

First of all I think the answer to your general question

Should software attempt to interpret input such as 3,14 correctly?

can only be unambiguously answered with a firm "it depends".

I think the keyword in my above comment "every properly localized application does that" is "properly localized". If you have an application which attempts to interpret the decimal according to the locale settings but doesn't bother to get the language or date formats right it would be very confusing. On the other hand if you adhere the language, currency, date settings etc. one would just expect that also the corresponding decimal separator is adhered.

To localize an application for several locales is not a small task though. In general it's split into two projects:

  1. The internationalization (i18n) of the application. That means all locale specific parts (like string content, text direction, collation, date formats, number and currency formats...) are abstracted and made configurable
  2. The localization of the application, which has to be done for each supported locale

You shouldn't attempt to localize your application without properly internationalize it first. You may make yourself a maintenance hell.

When the application is changed both these aspects also have to be continuously maintained. Considering these implications the decision to provide a proper localization is oftentimes an all or nothing consideration. You have to decide if its worth it, which in turn might depend on many factors, like the type of application, the customer base your resources etc. But if you decide to do it, you should do it properly and it's hardly just a matter of getting the decimal separator right.

That all being said there a still exceptions though. E.g. for a calculator application a complete localization probably doesn't matter too much, but its just convenient to be able to use either a comma or a dot as a decimal separator. E.g. in the Apple "Calculator" I can use a dot instead of a comma, but its always displayed as a comma. If I use spotlight to do calculations the comma and dot are displayed literally but interpreted interchangeability (it only gets confused if I mix thousand separators in, eg 1,234.56 gets interpreted as 1.23456 but 1.234,56 gets correctly interpreted as 1234.56).

But exceptions not only apply for simple applications. If you look at a german keyboard layout you can see that there is a comma at the numeric keypad where there is a dot at the english layout. So if you have an application which requires lots of numeric inputs, users expect to be able to use the comma as a decimal separator. It's simply an ergonomic matter.

In my opinion the localization effort is oftentimes done too far, which can lead to surprising results. E.g. if I ex- or import CSV files from Excel or LibreOffice Calc it depends on my locale setting in how dots and commas in fields are interpreted. Sure, it should be adhered in display and input, but should that affect the file format!? I even had to change my locale system setting in order to be able to import certain CSV files. Of course one could argue that CSV is not a real standard and just and ad-hoc format, but its still confusing and counterintuitive.

Also POSIX defines locale settings, which are stored in environment variables. But the results with certain shell builtins can be surprising:

$ export LC_NUMERIC="en_US.UTF-8"
$ printf "%'f\n" 1234.5678
1,234.567800
$ export LC_NUMERIC="de_DE.UTF-8"
$ printf "%'f\n" 1234.5678
bash: printf: 1234.5678: invalid number
0,000000
$ printf "%'f\n" 1234,5678
1234,567800

What does that mean? Ok, I have to provide the right input format when I change the locale. But what's the use of a format function if I have to provide the right format myself? And isn't "shell" also a scripting language? That means changing the locale changes the semantic of the language itself!? I guess it's not always so clear cut, what is interactive and non interactive input...

Even though your question is specifically addressing input, I want to provide least one practical tip (and that should apply whether or not you decide for the localisation of your program): if you have to display numbers between 1 and 999 don't use 3 decimal digits if you have the choice. A number like 1,234 might be interpreted as 1234 or 1.234 because by looking into the number itself its not clear if the ',' is a thousand separator or a decimal separator. Whereas for a number like 1,23 it' unambiguous. But that's just my own "private" rule. I'm actually curious if there is an "official" usability guideline for that. Maybe one of the experts could comment on that?

Of course there is no such tip if you have integers between 1000 and 999999 and have to use a thousand separator. But normally its clear from the context if the number has to be an integer, so its less of a problem.

  • 1
    There is an unambiguous digit grouping symbol: thin space. Wikipedia says that it is officially endorsed by SI/ISO 31-0 standard, as well as BIPM and IUPAC, and a couple of other bodies. – Ruslan May 31 at 16:46
  • Yes, resorting to a thin space was what we even did in an application. But it felt like cheating since it doesn't solve the localization issue as a whole. Also, the harder problem is how to interpret input. Over output one has usually complete control. – David Ongaro Jun 5 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.