namespacesRequired are not loaded for fallbackLng

After converting one of my apps from just a react-i18next example to next-i18next, I noticed a rendering glitch in one place when a non-default language is chosen. As it turned out, I simply forgot to add one translation string for that language. The reason why the bug did not show itself before was because fallbackLng was successfully leveraged. After the switch, initialI18nStore stopped containing translation strings for the default language. When fallbackLng is manually set or when the app is in production mode, the string from a fallback language is rendered, but after a delay (following async namespace fetching).

Should the current behaviour be changed, so that partially translated non-default languages still produced a working app that does not blink right after loading?

Related lines: https://github.com/isaachinman/next-i18next/blob/fa04883f3b79d84949cd7853f94cd350a99d7ce6/src/hocs/app-with-translation.js#L88-L95

[isaachinman]

Hi @kachkaev, happy holidays to you.

Yes, I think we should indeed be loading in the namespaces in the fallback language if it’s not the same as initialLanguage. It’s not just about fallbacks in the case of user error (failure to translate) - sometimes applications specifically want certain content to be in English (for example), even on foreign lang pages.

[kachkaev]

Hi @isaachinman! Sorry for a slow response, I’m still in the process of returning back to reality after the winter holidays 😅

I also believe that https://github.com/isaachinman/next-i18next/commit/463520acf274928df73b8e2dc709b65a2915b85c solves the issue – you got it right! Here’s an MWE: https://github.com/kachkaev/next-i18next/tree/issue-72-reproduction (the branch is on top of 0.16.0, before your fix)

Here’s is how page loading looks in prod mode (yarn build && yarn start):

As you can see, h1 renders on the server, but when client-side rendering kicks in, the string disappears, because en is not a part of initialI18nStore. When index.json and common.json are asynchronously fetched, another client-side render fixes things. The flickering of the header may be invisible by default given that the local network is pretty fast without throttling.

Rebasing my MWE branch on top of your master following by a rebuilt of the lib solves the problem! Opening page source reveals that common and index namespaces for both de and en are now a part of nextI18nStore, so no client-side fetching and therefore re-rendering is needed. Feel free to close this issue unless you want to ask something.