Description:
With locales using comma as decimal separator, the numpad dot is interpreted as such in document, but not in the interface.

Steps to Reproduce:
1. In the menu Tools > Options > Linguistic parameters, select a user interface and a locale setting using comma as decimal separator (such as french or german).
2. Uncheck "decimal separator key: same as locale setting"
3. Go to a form using decimal number. (In Writer: Format > Page > Width ; In Calc: Format > Row > Height)
4. Type a decimal value as "3.14", with a dot, and unfocus the field.

Actual Results:  
The dot is ignored. The field takes "314" or the max possible value.

Expected Results:
LO interprets the dot as a decimal separator.


Reproducible: Always

User Profile Reset: No

Additional Info:
I think the problem comes from the incomplete support of the locale by the OS. However:
1. In the language option form, since user interface and locale setting are set just above the choice of the decimal separator, the contract between the user and LO is explicitly "We'll use the dot as the decimal separator in the documents AND in the interface".
2. I tested this behavior with other softwares, as Gnome-calculator and Inkscape and they interpret the dot as a decimal separator, as expected.
3. In Calc, for instance, this behavior constrains the user to make a difference wether he is in a form or in a cell formula. It's really anti-ergonomic.

Solution 1: (If the problem comes from the OS)
Override OS behavior and interpret numpad dot as a comma in the forms when it's the expected behavior.

Solution 2:
In the language option form, change the "decimal separator key" checkbox to a multiple choice, so that the user can explicitly choose to interpret the numpad dot as a decimal separator.

Solution 3:
Add a warning: "this option doesn't work with every OS"

Solution 4:
Remove the checkbox on Linux.



User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0