jquery globalize issues with parseFloat validation

I am trying to use the jquery globalization plugin (https://github.com/jquery/globalize) to work with asp.net mvc3 client side unobtrusive validation. I have tied in both the en-CA and fr-CA cultures and was seeing some discrepancies between what the plugin accepting as a valid number vs what the service side validation was accepting. Here is some examples of calling the Globalize.parseFloat method with different inputs with the two cultures and what I am getting out (bold indicates that server side validation doesnt validate the number) fr-CA

• Globalize.parseFloat("7.12", 10, "fr-CA") returns 7.12
• Globalize.parseFloat("7..12", 10, "fr-CA") returns NaN
• Globalize.parseFloat("7,12", 10, "fr-CA") returns 7.12
• Globalize.parseFloat("7,,12", 10, "fr-CA") returns NaN
• Globalize.parseFloat("7 1 2,12", 10, "fr-CA") returns 712.12

en-CA

• Globalize.parseFloat("7.12", 10, "en-CA") returns 7.12
• Globalize.parseFloa开发者_开发百科t("7..12", 10, "en-CA") returns NaN
• Globalize.parseFloat("7,12", 10, "en-CA") returns 712
• Globalize.parseFloat("7,,12", 10, "en-CA") returns 712
• Globalize.parseFloat("7,,1,,2.12", 10, "en-CA") returns 712.12

Stepping through the parseFloat code looks like this is the intended output but I cant see how this is intended so I am hoping I am missing something ... or is this intended?

Thanks

---

Looks like this is a known issue in the globalization plugin (see https://github.com/jquery/globalize/issues/46). Looks like I will have to run my own regex to make sure it is in the right format for client side validation (good thing I only have to deal with two languages at the moment :)

---

Since parseFloat is inside, it runs first, wrapped by Globalize. parseFloat isn't really designed to handle complex strings.

---

The parseFloat method on the client side just ignores the thousand separators, so this is why Globalize.parseFloat("7,,1,,2.12", 10, "en-CA") returns 712.12 (the thousand separator in this culture is a ',').

The thousand separator for the fr-CA culture is a space, this is why Globalize.parseFloat("7 1 2,12", 10, "fr-CA") returns 712.12.

The decimal point can only occur once. For en-CA this is a '.', for fr-CA this is a ','. So all examples containing more than one decimal point will return NaN.

The only thing I cannot explain is why Globalize.parseFloat("7.12", 10, "fr-CA") returns 7.12. This is strange because neither the decimal point nor the thousands separator is a '.' in this culture, so this should return NaN.