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:
- 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
- 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.
