Fallback locale in case formatMessage failure

[sakarisson]

Hey, thanks for a great library!

Currently I'm in the process of converting our ancient, manual i18n logic to something more streamlined, and I think this library seems like a great fit!

I was wondering though, if it would be possible to set a default locale that would be fallen back to in case formatMessage fails when a local key is missing. In our project, we sometimes make releases before all our translators have translated each new key. In this case we want to fall back to English.

For example, let's say we add a new message, and neglect to translate it to German. If we call formatMessage for that key in DE locale, we don't have a German translation. In this case, I'd like to fall back to English. Only if English key wouldn't exist either, should we fall back to rendering the key itself. Is this possible? I didn't find support for this behavior in your documentation.

[joshswan]

There isn't currently a locale-based fallback mechanism for formatMessage. That's something that I could potentially explore adding or accept a PR for, though the mechanism for deciding the fallback locale would need to figured out (not everyone will want English).

That said, there are a couple of workarounds that may or may not help:

• Use the defaultMessage option/prop and set it to the English translation. This doesn't allow formatting/replacements currently (it's just treated as a string), but it would definitely hide the message key.
• Add the English translations to your German translations object so that all keys are present in the German translations, even if some are in English. You could do this manually or potentially just write a quick function that copies any missing keys from the English object to the German one and do this before even passing the messages to GlobalizeProvider.

[sakarisson]

Thanks for your response

(not everyone will want English).

Definitely. I used English as an example, but in practice the fallback locale would probably be decided from a prop.

Add the English translations to your German translations object so that all keys are present in the German translations, even if some are in English. You could do this manually or potentially just write a quick function that copies any missing keys from the English object to the German one and do this before even passing the messages to GlobalizeProvider.

Yeah, this is basically the workaround that I opted for. It has a bit more steps than my example, but essentially:

  loadMessages({
    de: {
      ...englishMessages,
      ...germanMessages,
    },
  });

For now I'm happy with this solution, as it seems to cover my needs entirely 👍

[joshswan]

Sounds good, that does seem like a decent workaround for now.

Per another issue that came up earlier today, a defaultLocale option/prop is now available. Currently it's used when the specified locale isn't available/loaded, but it could also be used in this situation. The problem is that it'd basically require initializing two instances of all the formatters (one with the specified locale/messages and one with the fallback locale/messages). Not sure if that's the best idea so I'll try to give this issue some thought.