You can clone with
HTTPS or Subversion.
Globalize.parseFloat("4,0",10,"en") yields 40, which is unacceptable. It should either work the same way as the standard parseFloat, parsing a number at the start of its first parameter (yielding 4) or parse the entire attribute as a number, recognizing that it does not fit into the number patterns of the locale (yielding NaN). The latter is preferable, as it would help in detecting data errors (like input "4,0" when a number in the English locale is expected).
It is highly probable that input like 4,0 in English locale is data error. It is extremely improbable that the user really meant the number 40
Technically, parseFloat, upon encountering a group separator, should test that there is a correct number of digits after it, as defined by numberFormat.groupSizes.
Similar considerations apply to parseInt, of course.
This sounds similar to the issue i am having where running as "fr" parseFloat will parse 10,5 as 10.5 but it also parses 10.5 as 10.50. It should return NaN. Its a real pain cause in my case I am submitting these values back to an asp.net app running in French which balks at 10.5 when it wants 10,5... otherwise I probably wouldn't care :)
Unfortunately any value that matches the en-US format will pass, it should really create an reg expression or something to evaluate if the entire string is valid.
The issue that en-US format is accepted on input is distinct from the problem that a grouping (thousands) separator is accepted all too liberally. It’s a difficult topic, since it might often be useful to allow both 10,5 and 10.5, though things get difficult if the period is used as a thousands separator - you can’t really accept 10.500 as the same as 10,500 if the locale definitions imply that it means 15000.
The French-locale manifestation of the problem I described is that
I think this problem is related:
The parseFloat() methods allow patterns with multiple thousands group markers like:
Globalize.parseFloat(",,9,,,,,,,9,,,,.99", 10, "en-US") -> is parsed to 99.99
I would expect that parseFloat() returns NaN.
Maybe adding a 'strictParsing' property might allow both scenarios, without breaking existing code by having the default set to false.
The property could be added to Globalize itself, might be useful for dates or such (can't think of any atm).
This issue still exists in the CLDR rewrite.