Possibility not to add `getStaticProps` on each page

[oceandrama]

Now to migrate to v8 of next-i18next it's necessary to add getStaticProps or getServerSideProps on each page. It may take a long time if you have a lot of pages. After this PR merged to Next.js is it possible to load all translations in getInitialProps in the _app component?

[isaachinman]

@oceandrama That is not something that next-i18next currently supports, but I suppose it would be possible in theory. The whole idea behind loading translations via getStaticProps or getServerSideProps is that each page will have its own translation dependencies, and we shouldn't send all translations to all pages.

[oceandrama]

@isaachinman I think this is fine, because even now you can pass undefined as an array of namespaces to serverSideTranslations function and this will work the same - all translations will send to the page

[isaachinman]

@oceandrama If you want to work on a PR, I would be OK with adding that type of functionality. However, it will never be advertised as the main installation/approach for next-i18next.

[stophecom]

@oceandrama I think you got a valid point - are you planning to do a PR? 😄

[aethiss]

agree, super valid point.

[rodilo]

Is there any progress on this one? Right now build times are crazy high with current implementation.

[isaachinman]

@rodilo Why do you believe next-i18next is affecting your build times?

[rodilo]

@isaachinman we had to move from next export when we implemented next-i18next into our app, so building became so slow on vercel, and I thought it had something to do with getStaticProps on each page.
But after some debugging, I found out that it was one of the imports from @material-ui/icons that was causing this ( don't know why).
After we removed that, build time went from ~25 minutes to ~8 minutes.

[ancyrweb]

@isaachinman

@oceandrama That is not something that next-i18next currently supports, but I suppose it would be possible in theory. The whole idea behind loading translations via getStaticProps or getServerSideProps is that each page will have its own translation dependencies, and we shouldn't send all translations to all pages.

This somewhat doesn't take into account layout where each page will render the same set of components with all the same requirements. I believe a good in-between would be to allow the developer to specify an array of dependencies that should be served on all pages. This in order to repeat adding the same one on every page using that specific layout.

[isaachinman]

I believe a good in-between would be to allow the developer to specify an array of dependencies that should be served on all pages.

That is the entire idea behind defaultNS, and the common namespace in the example.

[ancyrweb]

I believe a good in-between would be to allow the developer to specify an array of dependencies that should be served on all pages.

That is the entire idea behind defaultNS, and the common namespace in the example.

Those still require the use of getStaticProps on each page.
But what I mean is to load the common namespace by default on every page, without having us to mark every page explicitly. This is what most users here wants, and that would provide convenient backward compatibility with those who gathered all their translation in the common.json file.

[akshitkrnagpal]

As anyone found any workaround for this?

[isaachinman]

@akshitkrnagpal There is no "workaround". Feel free to work on an actual PR, though!

[akshitkrnagpal]

@isaachinman Okay. Thanks. We (temporarily) have a setup where we load all translations at once. The reason is we don't have translations separated in namespaces (I know, I know)

I will try to do this.

Add serverSideTranslations in getInitialProps of _app.js and modify AppWithTranslation to use _nextI18Next from appProps instead of appProps.pageProps

Do you see any potential issues in this? Can this work?