Grouping and decimal marks vary by locale and must adapt

What it is

Some regions use a comma as the decimal mark and a point or space for grouping (1.234,56); others reverse that (1,234.56). The same characters differ by three orders of magnitude across the two conventions. Locale-dependent numeric punctuation makes parse and display follow the user’s convention, not the developer’s keyboard. The issue is the role of comma and point, not currency, and not metric versus imperial.

Why it happens

People read “1,234” as one thousand two hundred thirty-four or as one point two three four, depending on the bills they grew up with. A parser hard-coded to “comma is grouping” turns a European 3,5 kg into 35 or a rejection. Display hard-coded to US style makes a European read 1,234.00 as one point two. Copy-paste across regions brings the source document’s marks into the slot; parse must tolerate both, or normalize on blur into a user-visible form so they see which number the system took. The decimal key on some layouts emits a comma; forbidding everything but an ASCII point blocks the numeric keypad.

Studying it

Recruit people who use different numeric conventions, have them enter amounts or weights with decimals, and compare parsed value with intent. Factors: whether the slot follows Intl locale, whether both marks are accepted, whether blur rewrites. Outcomes: order-of-magnitude error, rejection rate. Include both 1.234 and 1,234 as stimuli. Do not test only on the developer’s machine locale. Amounts in logs that are exactly 10× or 1000× off are punctuation-error clues.

Where it stops holding

Dots in account numbers, order IDs, and version strings are not decimals and must not be localized as numbers. Program config and API debugging aimed at developers are safer with one computer decimal. Mixing “follow browser language” and “follow account region” on one form gives two slots different parse rules. Screen readers also speak “comma” or “point” by locale; if display and parse disagree, the auditory channel reports a different number than submit.

Applying it

• Let parse and display follow the user’s locale: decimal and grouping marks take that locale’s roles.
• On blur, rewrite the value in that locale’s canonical form so people see the number the system understood.
• Accept a comma or point from the numeric keypad as the decimal mark; do not accept only an ASCII point.
• Verify by entering 3,5 under a comma-decimal convention and checking storage is three point five. Then enter 1.234 under a point-grouping convention and check it is one thousand two hundred thirty-four. Either magnitude flip means the marks are still frozen to the developer’s keyboard.

Related

• Within the group: E2.19.1 Money input must name the currency; do not let people assume the current one · E2.19.2 Unit input must accept a familiar system and convert · E2.19.4 Number–unit coupling errors are hard to notice before submit
• Adjacent: E2.07 Input masks · E2.08 Character limits
• Search terms: locale-dependent numeric punctuation · decimal comma · grouping separator