Getting empty server side translations on build

Describe the bug

Next does page building asynchronously, and on occasion certain serverSideTranslations calls return empty even though the translation files exist.

Seems to happen when using a separate backend for the client-side.

Occurs in next-i18next version

next-i18next: 11.0.0

Steps to reproduce

Example repo Run npm run build and check console for logs of empty translations.

Expected behaviour

Translations should be loaded correctly.

Additional context

I’m pretty sure the use of the globalInstance on the createClient is what is causing the error, as I comment that out to always create a new client it works as intended.

[joaomanke]

Regarding issue 1897, I’m down to contribute with a PR. I’m currently stuffed at work, but I can try to get something going later this week or next week.

[joaomanke]

Oh yeah, server and client have different need for sure, however when working with next we actually have 3 “sides”:

• server: apis, data fetching methods (getServerSideProps and others)
• client:
  • server version (SSR or build time SSG)
  • browser version (hydrated version on the user’s side)

While the server and client parts do have different needs (ie. HttpBackend vs FileSystemBackend), the server and browser version of the client should match as best as possible, React 18 actually throws an error now when they don’t (html wise).

In my view what could (or should) be done:

Decouple appWithTranslations from serverSideTranslations:

These are executed in different stages and are used in distinct enough ways that they should be isolated from one another. The point where they meet is in the createClient function, which has a browser and a node version. IMO serverSideTranslations should use the node one while appWithTranslations should use the browser one always.

“Bring your own global”:

The node version createClient, using globals internally is a bit dangerous, as you don’t really know when the code will be executed exacly (is it on build? on the server? a mix?), if instead you allow (or force) the user to instanciate their own “global” instance they can instanciate it before everything starts going, and we don’t have to worry about instanciating on the go, unless nothing has been provided, in which case we always instanciate a new one for each call.

With this the user could configure and share with other libraries that can share a i18n instance as well, plus this is the only difference between the node and browser version of createClient, therefore in this case we could reuse the exact same function passing a “global” as needed.

Let me also say that I am no expert, so these are just things tha I would prefer/do, I am not familiar with every i18n use case.