8000 Expressing regional overrides for a given locale · Issue #995 · tc39/ecma402 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Expressing regional overrides for a given locale #995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
fpapado opened this issue Apr 21, 2025 · 3 comments
Open

Expressing regional overrides for a given locale #995

fpapado opened this issue Apr 21, 2025 · 3 comments
Labels
s: comment Status: more info is needed to move forward User Preferences Related to user preferences

Comments

@fpapado
Copy link
fpapado commented Apr 21, 2025 •
edited
Loading

Hi, feel free to redirect me if there is a better place for this inquiry. I have looked through a few dozen issues and repositories, and my hunch is to ask here, but I might be wrong 😌

Small problem statement

Imagine there is a website with 30 languages for its UI (taking an example from my workplace, https://wolt.com), provided to users via a layered strategy of a language selector and locale negotiation. “Languages” here refers to the UI translations and can be locale tags without a region (e.g en, fi), but also with a region (e.g. both de and de-AT are available)

This website wants users to access formatting for currencies and dates and so on in their own regional preference, on top of the app language.

Two examples:

  • Avoiding US-centric default formatting for en, while not being overly Eurocentric with userland code overrides
  • A Greek immigrant living in Finland might prefer English or Finnish for the UI text, but prefer Greek regional currency and date formatting.

I can imagine a scenario where we provide a “region” selector in our UI (utilising DisplayNames) to synthesise a formatting locale. This seems simpler to present to users compared to more fine-grained formatting settings. However, I am not sure how to represent it in a way that browsers will use it.

The main question

While researching this topic, I came across the region override Unicode extension Region Override, such as en-u-rg-fizzzz, fi-u-rg-grzzzz, or de-DE-u-rg-fizzzz.

My question is:

  • Is this an appropriate use of regional overrides?
  • Is there something in the spec that would support this use in formatters, or is it up to implementers to support it?

I did some brief tests in Node 22.14.0, and did not get any observable difference in output:

const amount = 1234.56;
const locales = [
  'en',               
  'en-FI',            
  'en-u-rg-fizzzz',
  'fi',                 
  'fi-GR',             
  'fi-u-rg-grzzzz',
  'el-GR'
];

const tableData = locales.map(locale => ({
  Locale: locale,
  Formatted: new Intl.NumberFormat(locale, {
    style: 'currency',
    currency: 'EUR'
  }).format(amount)
}));

console.table(tableData);

My intent in the latter cases would be for the currency to be formatted with the el-GR separators.

(I’ve yet to do a comprehensive browser comparison due to travels)

I found some related discussions about fine-grained settings like the clock, week start and calendar Unicode extensions. I also found open questions about how browsers might expose those to websites (I didn’t find much mention of exposing the region override, but maybe this is not the right repo for that request).

I am interested in this from an ecma402 perspective. Imagine that the website collected this info from users via a UI. Is there any guidance on whether it would be supported by Intl formatters?

Aside: some Accept-Language headers we have observed from iOS apps

(I understand the difference in privacy concerns and fingerprinting between native apps and websites, I bring this up mostly for discussion 😇)

While doing an audit of real Accept-Language headers from requests to services, I noticed that iOS native apps provide locales like this:

Accept-Language: fi-GR;q=1.0, en-GR;q=0.9, el-GR;q=0.8, de-AT;q=0.7

iOS does this when I select my system language priorities as Finnish, English, Greek, German (Austria) and a separate system Region preference as Greece.

Modulo my lousy search skills,
fi-GR seems to not exist in CLDR, but it would be one potential descriptor for what we want to achieve. On the other hand, a language such as German (Austria) but a region of Greece is not representable by this strategy and stays just de-AT.

Wrapping up

Please let me know if there is any more information that I can provide, for example any motivation, tests, or any relevant data from production. I might have misunderstood something! I am happy to move this elsewhere if you think there is a better forum 😊
@fpapado
Copy link
Author
fpapado commented Apr 21, 2025

Oh no, on second inspection, it seems that there is already an issue open #370. I have no idea how I missed that earlier, apologies for the duplication. I can move some of the motivation there if you believe it is useful, or we can close this one altogether if it is sufficiently motivated.

@sffc
Copy link
Contributor
sffc commented Apr 21, 2025

That's right; we have a lot of issues open regarding User Preferences that differ from locale defaults. You found #370 for adding the -u-rg keyword, which behaves the way you described.

@sffc sffc added s: comment Status: more info is needed to move forward User Preferences Related to user preferences labels Apr 21, 2025
@hsivonen
Copy link
Member
hsivonen commented Apr 22, 2025 •
edited
Loading

I did some brief tests in Node 22.14.0, and did not get any observable difference in output:

Notably, the results for the actual number part are closer to what you seem to be expecting if you remove the currency option bag. AFAICT, CLDR has had insufficient care applied to how the number formatting overrides interact with the currency formatting mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
s: comment Status: more info is needed to move forward User Preferences Related to user preferences
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hsivonen @sffc @fpapado
0