Internationalization: Different locale for translations and formatting

[rothsandro]

Hi,

The I18nProvider only accepts a single locale which is then used for translations and formatting (date, numbers, ...). Is it possible to have a separate locale for translations and formatting?

Some content in our app needs to be entered in all active UI languages. That's why the administrator of the customer can define which UI languages are active and the employees can only select the active ones. However, for formatting of dates/numbers/... there's not really a reason to have this restriction and employees should be able to select a different locale.

[snowystinger]

I18nProvider accepts any BCP 47 locale, so you can do things like:
en-US-u-ca-iso8601-nu-thai
Which will use US english for all translations, the iso8601 calendar for dates, and the thai numbering system. Does this work for you?

[snowystinger]

I should note, we haven't tested with many of these combinations, so please let us know if you find any issues.

[rothsandro]

They are not that useful anyway (at least for us), as they only cover some translation/formatting combinations.

[snowystinger]

Another thing I came across, the OS and the browser and node may all differ in terms of what the combinations do. This can be partially attributed to Chrome and Firefox using CLDR though with some discrepancies, and Apple using its own data which it doesn't always push changes to the actual CLDR.

Which browser were you testing in out of curiosity?

Would you be willing to put together a very small codesandbox or stackblitz with a setup you're trying to accomplish and details on where it differs from expectations?

[rothsandro]

I was testing with Brave on macOS. Sure, I can create a Codesandbox/Stackblitz tomorrow.

[rothsandro]

Here's a demo showing a few different cases. I hope that helps, let me know if I should change / extend something.

https://stackblitz.com/edit/vitejs-vite-btgwkpcu?file=src%2FApp.tsx

I noticed that en-CH is not fully correct if an English UI and a formatting with de-CH is desired because for de-CH we get "1.12.2025" but with en-CH we get "01.12.2025". While the latter may be acceptable as well (actually, I think most people would prefer this format) it doesn't match the normal behavior of de-CH in the browser. In macOS we also get "01.12.2025" by default but here the exact date format is configurable.