With the new web-interface default that the browser number input is used by default we see problems entering numbers with digits after the decimal point. The reason is probably that the browser with a german (or austrian) locale insists that a number must contain digits after a decimal *comma* (german and austrian locales have a decimal comma not a decimal point). Which in turn cannot be parsed by roundup's mechanisms. So we can neither enter a decimal comma (because the cgi mechanisms cannot parse this) nor a decimal point (because the browser won't let us). When, e.g., entering "3.5" the browser issues the message "Please enter a valid value. The two nearest valid values are 3 and 4."

So I guess we should make the config-setting
use_browser_number_input
defaulting to "no" not "yes" as it currently doesn't work for non-english locales

It might also be that some browsers allow only integers or that I've made an error when refactoring the html generation with the new config variable. I've not investigated further. The browser in use is probably Chrome.

Hi Ralf:

> When, e.g., entering "3.5" the browser issues the message
> "Please enter a valid value. The two nearest valid values are 3 and 4."
 [...]
> It might also be that some browsers allow only integers or that I've
> made an error when refactoring the html generation with the new config variable.

Interesting. Are you sure the property is a number and not an integer? Integer
valued properties include "step=1" to make the number an integer. (You can enter
floating point numbers, but they will error.) The prompt about two nearest values
makes it sound like it expects an integer.

>So I guess we should make the config-setting use_browser_number_input
>defaulting to "no" not "yes" as it currently doesn't work for non-english
>locales

You note that using "3,5" to enter three and a half fails in locals that
use a decimal comma not a decimal point for a number property. It passes the browser
checks, but the number property parser doesn't handle a decimal comma.

I can think of four ways to handle this:

  1) set default for native input for numbers to off/false and update doc
     to discuss limitation when turning it on. This disables the native input
     for Numbers and Integers.

  2) add a WEB_USE_BROWSER_INTEGER_INPUT setting. Turn off WEB_USE_BROWSER_NUMBER_INPUT
     and set WEB_USE_BROWSER_NUMBER_INPUT to on. Then change the code for
     IntegerHTMLProperty::field() to use WEB_USE_BROWSER_INTEGER_INPUT.

  3) modify HTMLProperty::__init__ to replace ',' with '.' when setting value, or
     add/override HTMLProperty::__init__ in NumberHTMLProperty to modify the
     value replacing ',' with '.' before calling super.__init__(). This could be
     confusing to people in other locales though as the number will be displayed
     with a decimal point not a decimal comma.

  4) parse the floating value with a locale aware string -> float method.
     To prevent the same confusion as in #3, we would need to use a locale aware
     method to format plain() or field() values as well. I think we have the
     browser's locale available for this. Handling values assigned on the subject
     line in email might be an issue though as I am not sure if we have locale info
     there.

I'm ok with #1 and a request for patches to handle cases 2-4.

The native integer input is really useful on a phone as the keyboard changes
and is much easier to use.