Basic formatter numeric should converse Uservalue from internationalized format to standard format

[idbr]

In the kauri-forms sample, when a localized numeric value (e.g. '3,14') is entered in the field 'Pi', a is-not-numeric validation error is produced. When a value with US locale is entered (e.g. '3.14'), it succeeds the numeric validation, and is formated following the current locale (in this case '3,14').

[idbr]

I was wondering if it should be considered valid if someone enters a correct numeric value in a locale that isn't his own, e.g. '3.14' with locale nl-BE.

I would say it is invalid, because of the ambiguity we get with '12,345.678' and '12.345,678', although this limits somehow the user friendliness.

[idbr]

Fix

[mpo]

The patch seems valid and a solid way to survive many possible mishaps.

The crux seems that the formatter isn't really operating in a way that can rountrip own values (ie parse own formatted strings) which in turn comes from the fact that the localeString() result doesn't match up with the new Number() argument.

Using the found numeric separators to deal with that assumes that those are derived from the current localString-trick on 9999.9 (see locale.js)

Before applying this, we should however properly deal with the mentioned i18n setting in the new issue #272 since that might alter the way 1000 and decimal separators are set in the first place.

[freya]

patch applied in r1571