In french locale, useNumberField replace dot by non-breaking space instead of a comma

[romain-inqom]

Provide a general summary of the issue here

In french locale, NumberParser of the @internationalized/number package replace the dot by a non-breaking space.

In fact, in France, the dot can be used as a decimal separator and never as a separator of thousands.

🤔 Expected Behavior?

In locale fr-Fr, the dot should be replace by a comma.

😯 Current Behavior

In french locale, useNumberField replace dot by non-breaking space.

💁 Possible Solution

In the file packages/@internationalized/number/src/NumberParser.ts, I suggest to replace this code :

    if (this.options.locale === 'fr-FR') {
      value = replaceAll(value, '.', String.fromCharCode(8239));
    }

by

    if (this.options.locale === 'fr-FR') {
      value = replaceAll(value, '.', ',');
    }

🔦 Context

No response

🖥️ Steps to Reproduce

To reproduce the problem, your Browser must be in French. You'll be able to reproduce the video manipulation.

Enregistrement.de.l.ecran.2025-03-05.a.10.49.37.mov

Version

latest

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS Sequoia

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[snowystinger]

This comes from the Intl NumberFormat, where the ',' character is the preferred decimal for the French locale. If we replace the '.' with a comma, we will have an ambiguous number, as it'd be akin to having multiple decimal points.
Perhaps the better solution would be to allow the regular space character and convert that to the non-breaking one that Intl.NumberFormat uses, but I think it'd be in addition to the decimal.

new Intl.NumberFormat('fr-FR').format(123456789.123)
'123 456 789,123'

Some references for where the choice for the usage of dot came from
https://en.wikipedia.org/wiki/Decimal_separator
https://www.reddit.com/r/French/comments/114sir7/decimal_points_in_numbers/
https://www.ibm.com/docs/en/informix-servers/15.0.0?topic=formats-numeric-monetary

we also consulted the Adobe Internationalization team

[romain-inqom]

Hello @snowystinger , thank you for your reply.

Perhaps I wasn't explicit enough in the description of my problem: we (french people) never use '.' as group/thousand separator. So when we use a '.' in a number, we use it once and expect it to be replaced by a ','.

I agree with you, to allow regular space separator and replace it by a non-breaking.

To be even more precise, I'm French, I live in France and I work for a fintech for which our users (accountants) want to be able to use the dot on the numeric keypad when entering decimal values.

[snowystinger]

Thanks for the reply. I'll bring it up again with the internationalization team.

[baptisteArno]

I confirm this is an issue. If we (french people) type 5.5, we are expecting it to be parsed as 5.5 not 55 😅

[snowystinger]

Thank you for raising the issue. I have discussed with Adobe's globalization team and french CLDR contributor. The consensus was that periods are ambiguous. France started to have recommendations against using periods as group separators in 1948, however, it was still taught in schools for a long time. As a result, depending on age or where someone went to school, they may expect it to be the decimal or they may expect it to be the group separator. To get rid of the ambiguity, it was recommended that we remove period as an allowed character and expand the group separator characters to allow all kinds of spaces so that they can easily be typed out on a standard keyboard.

I've opened a PR to address it here fix: French number parsing ambiguity

[baptisteArno]

Thank you for raising the issue. I have discussed with Adobe's globalization team and french CLDR contributor. The consensus was that periods are ambiguous. France started to have recommendations against using periods as group separators in 1948, however, it was still taught in schools for a long time. As a result, depending on age or where someone went to school, they may expect it to be the decimal or they may expect it to be the group separator. To get rid of the ambiguity, it was recommended that we remove period as an allowed character and expand the group separator characters to allow all kinds of spaces so that they can easily be typed out on a standard keyboard.

I've opened a PR to address it here fix: French number parsing ambiguity

Sounds reasonable 👌

[romain-inqom]

Thanks @snowystinger.