Feature request: Multiple base locales

[linearza]

• I am on the latest ember-intl version
• I have searched the issues of this repo and believe that this is not a duplicate

Hi there! This is a feature request for having multiple base locales.

In short, we have multiple en and fr based locales, with their region specific overrides. Eg fr and fr-fr, en and en-gb

For the fr- locales we want to use fr as the fallbackLocale and for en- we want to use en as the fallbackLocale.
Addtionally we want to ensure that our developers can still only add the initial en translations during development, but that there's a way for hydrating the other base locales with these new keys. In other words, ensure that fr contains all en keys even if just the English ones for now.

So to summarise:

1. Allow for dynamic fallbackLocale at build time
2. Allow for hydrating all non-en locales with missing en keys

Thanks!

Discord chat here: https://discord.com/channels/480462759797063690/487648547685269515/973167561376141352

[linearza]

As an alternative solution for the time being, we're handling this merging on the backend for now, allowing us to parse the data as required and letting the UI only make a simple api request, but having this ability in the ember-intl lib would make that redundant and would make ember-intl so much more powerful as this is a common issue Ive run into on multiple Ember projects!

[sandstrom]

This sounds like a backend or build-time concern to me. You'd just add the fallback strings to your translation data as you please (we do something similar).

Unless I've missed something, I'd say that this doesn't really fit into ember-intl.

[linearza]

Having built more than one of these implementations I can say the requirement is pretty similar and simple - having this ability on the UI would eliminate the need for the backend dependency and allow for tapping into some of the nice ember-intl functionality which is only possible if the translations live on the UI, so still think this is a valid feature request!

[robertpbaxter]

I would upvote this feature request myself. Our app uses an en-us locale as a default, but we also support another number of English variants (en-gb, en-au, en-nz) and French (fr-ca) at client request. I just discovered that the app breaks for users whose browsers are set to en-ca. Unless there's a better workaround available, I'm going to have to overwrite the service to handle any unsupported language variants manually.