[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #11029(new unknown)

Opened 3 weeks ago

Number Formatting fallback

Reported by: yloubry@… Owned by: anybody
Component: numbers Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:



Today I look at how Numbers get formatted and it appears to me that the regional aspect of an app along with sometimes the language spoken in that region is what defines entirely how a number is formatted.

When I open the language preference in my OS and chopse English as my preferred language and FRANCE as my region. The OS automatically presented me with Comma separated decimal point.
The number was formatted with regard to the regional setting I set which seems to be correct.
Now while this would result as the locale to be en-FR, I was curious to test this using the Intl object as well as the toLocaleString API all available in latest browsers.

The result appeared to be different. I think that's because there isn't any CLDR data for en-FR and the API most likely fallback to the language part of the locale.
en-FR results in a period as decimal seperator
de-FR results in a comma as decimal seperator

My question: Is ok to assume that we should try to fallback on the region first correct?
Whenever a region has multiple language nuances like Canada, then the language should take priority.
So en-CA gives you a period
fr-CA gives you a comma
de-CA would give you a comma based on the fact the "de" language is widely spoken in Germany which is part of the region using comma as a decimal point? This part is all debatable and also part of some edge case that we don't encounter often in the real world but that needs to be taken care of anyway.

Any thoughts on this?



Add a comment

Modify Ticket

as new

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.