Next-i18next: Provide i18n instance even when serverSideTranslations is not used

[jvcmanke]

Is your feature request related to a problem? Please describe.

When using getStaticPaths with fallback: true the fallback page does not run getStaticProps however I still want to render the translations for my _app or other components like loading spinner test using my i18next configuration.

I can do it using i18next-http-backend as I do with a few parts of my UI, however in this case the configuration is not loaded and i get the warning:

react-i18next:: You will need to pass in an i18next instance by unsing initReactI18next

Because next-i18next only adds the I18NextProvider if _nextI18Next is present in pageProps.

Describe the solution you'd like

Always wrap with the I18NextProvider just don't provide any server side translations.

Describe alternatives you've considered

I could wrap with my own instance but I don't see a reason next-i18next should't always provide the i18n instance.

Additional context

This would also mean that dynamic routes that don't want to use getStaticProps/getStaticPaths could still utilize the same i18n instance/configuration to fetch their translations client-side.

[jvcmanke]

P.S.: I can come up with a PR if you agree.

[isaachinman]

I'm not sure i18next-http-backend is the best solution for this.

Relevant documentation for fallback pages can be found here. In general, I wonder how the Vercel team expects users to translate fallback pages, or if this use case was overlooked entirely.

I would start by enquiring on the NextJs repo, rather than fetching translations on the client side, via HTTP.

[jvcmanke]

Right, the fallback was just an example why it would be useful to have the i18n instance available at all times.

I don't see any reason where not having it there is better that having it there, while having it provided even without translations allows reuse of the same configuration everywhere.

I would start by enquiring on the NextJs repo, rather than fetching translations on the client side, via HTTP.

Translations through HTTP is necessary in certain situations. For example, I don't necessarily want to preload translations for parts of the app that my users might rarely access, dynamic options with translations for select components and authentication locked translations to name a few.

[isaachinman]

Feel free to work on a PR. Just bear in mind it will need test coverage. Thanks!

[skrivanos]

+1. I'd like this for cases with dynamic routes where using getStaticPaths just isn't feasible and getServerSideProps causes unnecessary latency. For instance if you have a user specific dashboard (located at like /projects/[id]) where all data is loaded on the client.

There's one better solution and that is for Next.js to make it possible to use getStaticProps without getStaticPaths for dynamic routes but I don't see that happening anytime soon: https://github.com/vercel/next.js/issues/14200

Edit: https://github.com/isaachinman/next-i18next/issues/993 seems like a dupe, but was closed.

[njarraud]

What is the current way of doing for dynamic routes that do not require getStaticProps or getServerSideProps other than for translations?

Nextjs requires to have getStaticPaths if getStaticProps is used for dynamic routes. I could use this solution with fallback: true but considering that serverSideTranslations is the only props in getStaticProps, it will build exactly the same file over and over again and I will end up with 1000s of identical pages. Am I missing something?

[dcodus]

Fetching translations client side is a huge requirement for us since we load components dynamically and they define the namespaces required. It was recommended to use i18next-http-middleware https://github.com/isaachinman/next-i18next/issues/1004#issuecomment-790013130 to achieve this however i was not able to make it work by simply including it in config.use. @isaachinman Would you be able to provide more details about how this needs to be wired up? Much appreciated!

[jvcmanke]

@skrivanos and @njarraud There is currently not a possible solution for this, I didn't have time to work on a PR yet, however it probably would be necessary to use the overrideConfig parameter in appWithTranslation.

@dcodus You actually have to use i18next-http-backend not the middlware, you have to pass the config to appWithTranslation as overrideConfig, also don't forget to set partialBundledLanguages to true, to allow both server and client site translations, and to check typeof window !== "undefined" before including the backend to only include it on the client side.

[dcodus]

@jvcmanke Thank you! Everything works as expected now!

[austinhale]

Quick question, based on reading these issues + the documentation, I have the following set up. I feel like I'm close but I keep getting a react-i18next:: You will need to pass in an i18next instance by using initReactI18next -- am I missing something to get this working?

// next-i18next.config.js

const i18nextHttpBackend = require('i18next-http-backend').default;

module.exports = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'fr', 'es']
  },
  partialBundledLanguages: true,
  use: process.browser ? [i18nextHttpBackend] : []
};

// app.tsx 

import { appWithTranslation } from 'next-i18next';
const nextI18NextConfig = require('../../next-i18next.config');

export default appWithTranslation(App, nextI18NextConfig);

// index.tsx 

import { useTranslation } from 'next-i18next';

const { t } = useTranslation('homepage');

<h1>
  {t('heroTitle')}
</h1>

[isaachinman]

@austinhale You are missing serverSideTranslations in your index.tsx file. The serverSideTranslations is the key function which reads translation data from the filesystem (or remote API, if specified), and passes it into your NextJs app as props.

[austinhale]

@isaachinman I’m new to the library so I’m still getting up to speed. Are you saying I should include the serverSideTranslations function and depending on the process.browser ternary, that will dictate whether the transaction actually occurs server side vs client side http?

[isaachinman]

@austinhale Yes, if you want to use i18next-http-backend (not sure why you do), then that flow would make sense.