width=0,1 saved as width=1 in locales that use a period as the decimal separator, such as English and Chinese

[matkoniecz]

URL

No response

How to reproduce the issue?

create node

tag barrier=bollard

add width=0,1

trigger confusion involving several people - see https://community.openstreetmap.org/t/what-width-0-can-mean-here/106666 https://www.openstreetmap.org/changeset/142886665 https://www.openstreetmap.org/note/3994430

Screenshot(s) or anything else?

tried search for comma and width in open issues here and tagging schema

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.27.3

Which browsers are you seeing this problem on?

Firefox

[matkoniecz]

apparently it may depend on something, reportedly does not happen in German locale

[1ec5]

In locales that use a comma as the decimal separator, such as German, the fix in #8769 (comment) ensures that both “0,1” and “0.1” produce 0.1 in the raw tags. However, in locales that use a period as the decimal separator, such as English and Chinese, “0,1” produces 1. Specifically, 0 immediately tags the feature with 0, then , has no effect on the tag, and 1 is interpreted as “01”, which becomes 1.

[matkoniecz]

updated title

note that some people use locales that does not match exactly their preferences as proper one may be unavailable

For example on computer I use EN / EN-UK / EN-USA to have communicates in English, what helps in search based on error messages and reduces my urges to fix bad translations to Polish that I would otherwise encounter. On phone I was able to select EN-Germany (so I do not get miles as unit or weird number separators).

[1ec5]

While you’re right that some non-English speakers use the English locale, probably many more English speakers use the English locale. In English, the comma functions as the digit grouping character, and the user has no reason to believe that digit grouping characters function as decimal separators. If I enter 3,1, I may be in the middle of entering 3141 rather than the digits of π. I haven’t checked if the fix in #8769 (comment) could be tweaked to also cover the inverse case, but that fix is still fragile, dependent on an assumption that the specific keys that accept numeric values are either very large or very small.

I think a more robust, less surprising fix for both cases would be to ignore the digit grouping character when the user inputs it, but still include it when formatting a number for display. There may be some edge cases due to the discrepancy between input and output characters.