The version of i18next used by NR's editor is quite old: v1.8.1 (at least 3 years old)
The version used by the runtime is v11.6.0 (a few months old).
Those two versions are so different that initializing i18next, loading namespaces, etc. has changed. I suppose this is a problem for NR-core developers as they have to cope with different ways to address i18next. But that's not why I'm writing this post.
While trying to create locales for a custom node of mine, I noticed that v1.8.1 (at least as configured for the editor) does not fallback the same way later releases of i18next do.
If my browser is set to use "fr-FR", i18next v1.8.1 will search for "fr-FR" locales and then fallback to "en-US" if not found ("en-US" being the default fallback language for NR). Later releases of i18next, will FIRST try to fallback to "fr" before going to "en-US" (as explained here: https://www.i18next.com/overview/api#languages).
It does not make much sense to create locales files for every variation of "fr" (fr-BE, fr-CA, etc.), so it's only logical to create one locale file for "fr" that will be used as an automatic fallback if the browser language is set to any variation of "fr".
Now I'm not sure if it's the way i18next v1.8.1 is configured in the editor or if it's the way it worked then compared to the latest releases of i18next. But one thing is certain: the i18next version as configured/used by the NR-runtime does not have that issue !
Maybe it would be interesting to upgrade i18next v1.8.1 to a more recent version ? And while doing that, maybe add an easy way to change the language (by using lng query parameter for example ?) if only for development/testing purposes ...
