Is your feature request related to a problem? Please describe.

There is already a fallback to use the defaultLocale if the message is not in the current selected locale. However, if the translated message has a ICU syntax error, the t function can throw an error.

For example, I translate with AI the .json files, and it wrongly translated the "other" to "autres" in French in this message for example: "message-key": "You have {count, plural, =0 {no followers yet} =1 {one follower} other {# followers}}."

Which throw an error, and instead display message-key in production.

Describe the solution you'd like

While of course, the best solution is to fix the translation.

Meanwhile until the fix is deployed, it would be better to fallback to the defaultLocale so that instead of the key, we still display something "correct" for the user even if it's not translated.

Of course, if even the defaultLocale throw an error, then we display the key, we don't have other thing to try, but hopefully that should not happen, as the defaultLocale can be type-safe, is more verified etc.

I believe it would make a better user experience than displaying the key, at least until the translation is correctly fixed.

Describe alternatives you've considered

Doing nothing: it's the developer responsibility to verify that all the translations have no message ICU errors.