What the float? Or what's up with z3c.form.converter.FloatDataConverter

Folks, z3c.form.converter.FloatDataConverter does not tolerate more than 3 digits after the decimal point, ever. That's UX fail for Dexterity types, and pretty much any z3c.form using stock converter, which is every form with a zope.schema.Float field AFAICT. This is due to regex validation in formatter from zope.i18n, can we fix this?

For now, I'm writing a converter override in my add-on, but this seems a curious problem. Can we fix this in plone.zpp.z3cform, perhaps? I'm happy to contribute that and docs if there isn't some other solution I am unaware of.

Any reason to not fix this in z3c.form? Anyway, if not there then an override in plone.zpp.z3cform is the right thing.

I am unsure of the the original motives of authors for using zope.i18n formatters? Aside from localizing the decimal point delimiter, is it safe to assume the following assertions?

  1. All locales use same characters for numerals and +/- indication;
  2. All locales represent decimal numbers left-to-right;
  3. Arbitrary precision to the right of the decimal mark is desirable;
  4. Decimal mark delimiter is the only thing that needs l10n via lookup of user's locale;
  5. ValidationError should only ever result from a formatter that is unable to handle input per above.

I would consider fixing this in z3c.form (or failing that, plone.z3cform.converter) if these assertions all make sense?


For reference, this is how I have worked around this, in an override:

The general approach is to only use the locale/formatter to get the decimal point/mark delimiter, and otherwise parse and serialize independent from zope.i18n formatting.

I may take some time soon to fix this in z3c.form in the coming weeks.


I am not that familiar with other handling of float/decimal values, but your assumptions are correct from what I know.

If it comes to a thousand delimiter eg 1,000,000.0000 this might become 1.000.000,0000 (i.e. in German). But afaik the widget does not use this form?