Localized numbers in fields are re-displayed in english after an invalid form submit

[michalbundyra]

Say we have a field containing a float number in french (with a comma as decimal separator). If the user enter 4,5 (a valid value) and submits the form but the form is invalid for another reason, the form is displayed again to the user with the number in english format (with a dot as decimal separator).
Is it normal ?

---

Originally posted by @berturion at zendframework/zend-form#23

[michalbundyra]

@berturion Yes; internally, the values are passed through a normalization filter first, prior to validation, and the normalized value is also what is used then to populate errors and form values.

---

Originally posted by @weierophinney at zendframework/zend-form#23 (comment)

[michalbundyra]

Ok, I understand. Is there a way to filter the values again before populating errors and form values in order to have values in a valid localized format? Because the problem is that the user has to correct already valid filled values he entered... It is quiet annoying, not very user friendly...

---

Originally posted by @berturion at zendframework/zend-form#23 (comment)

[driehle]

@weierophinney @bakura10 What would your take be on localizing values on the way going from model to the form? I have the same issue as @berturion, so my models obviously have normalized values (0.05), doing the localizedToNormalized conversion as part of the form filter is also working quite well. However, how am I supposed to get the normalizedToLocalized conversion working prior to rendering the element? I could manually convert outside of the form magic, but then I cannot use model binding anymore and the issue with values being normalized when the form is rendered again would still remain.

[kynx]

@driehle Have you considered using <input type="number">? That way numbers get submitted in "C" locale (ie 1234.56) and no normalisation is necessary in either direction. Working with the values in javascript is similarly much simpler and less error-prone - mixing up decimals and thousands can be very expensive 😉

It's up to the browser to localise them. Most do OK with the decimals, but omit thousand separators. I've never had anyone complain about that though - and I support 30+ locales. Best of all mobile devices will display a keypad for entry - very important these days.

[driehle]

@kynx Thanks for the hint. Indeed this seems to be a proper solution to this case. Initially, I was thinking about other cases as well, e.g. some string pre-processing, but probably you are right and these are rather rare cases compared to numbers.