Option to prefer local resources

[medihack]

I am using i18next in a Next.js app with server-side rendering. For that, I am initializing the language resources with data from the server, but allow to switch to other languages by fetching resources via i18next-http-backend. Let's now say I have an en language in the initial resources, but the current locale is en-US. The client would make an unnecessary network call as this exact locale is not in the initial resources, but the server still only provides an en language.

In a server-side rendering scenario, it would be nice to have an option to prefer the already provided (initial) resources before making a network call. So if the current locale is en-GB it should first check en-US and en in the local resources, but if not found then reload it.

But maybe I miss something here, why I want to discuss it before creating a feature proposal.

[jamuhl]

https://react.i18next.com/latest/ssr#passing-initial-translations-initial-language-down-to-client -> initial set language should be same as server and initial store should contain in eg. en-US case both en-US and en resources (if there are deviations in en-US from en)

[medihack]

The problem is more when resources only contain en (from a preloaded store), but the client has en-US set as lng. The client will then try to reload the missing en-US language from an external source and only use en when no en-US resource was returned. Here is a little sandbox that demonstrates the problem.

A possible solution seems to be the supportedLngs option (commented out in the sandbox). When set to en then en-US is ignored (no network request) and en is directly used from the preloaded resources. This presumes that all available language codes must be known beforehand and set as supportedLngs.

Another solution seems to be to store an empty object for en-US and the appropriate namespace in the resource to preload on the server (something similar to the razzle-ssr example. Then the client does also seems to fall back to en without a network request (sandbox example)

Another solution would be a new preferLocalResources option ;-) In the above example, it would first check if en-US is available in the local resource, if not it would try en and dev in the local resources. And only if none is available it would make a network request and try to reload it externally. But from looking at the queueLoad it seems a bit too tough to implement as all language codes are treated independently.

Sorry for the long message and many edits. Just wanted to document this little journey for others that may have the same problem.

[jamuhl]

Adding a function that changes the loading behavior just for this "edge"-case isn't the best idea as there are other options -> like you see in the razzle sample resolution of translations works already with a fallback from en-US to en to fallbackLng

Preparing a current initialStore like https://github.com/i18next/react-i18next/blob/master/example/razzle-ssr/src/server.js#L65 and having the client using that (useSSR) should work out of the box.

Not sure if you already had a look at https://github.com/isaachinman/next-i18next or the many samples out there?

[medihack]

@jamuhl Thank you very much for the help. I am using something similar now to the razzle example, but without the need to set supportLngs on the client (which I guess is required in the razzle example and can be circumvented by replacing L73 in the example with req.i18n.services.resourceStore.data[language][namespace] ?? {};).

I know of next-i18next (even helped to fix a bug there), but my scenario is much more complicated. A medical web app with a plugin architecture and multiple languages at the same time on the same page. It would be hardly possible without the power of i18next. So a big thank you for supporting this library! We will open-source our app later this year and I will leave some notes on how we implemented it.