Expressing regional overrides for a given locale

[fpapado]

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]

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]

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.

[hsivonen]

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.