next-i18next

The easiest way to translate your Next.js apps (with pages setup).

If you are using next-i18next (pages directory) in production and like to unleash some super powers, you may have a look at this blog post.

If you're using Next.js 13/14 with app directory, there is no need for next-i18next, you can directly use i18next and react-i18next, like described in this blog post.

What is this?

Although Next.js provides internationalised routing directly, it does not handle any management of translation content, or the actual translation functionality itself. All Next.js does is keep your locales and URLs in sync.

To complement this, next-i18next provides the remaining functionality – management of translation content, and components/hooks to translate your React components – while fully supporting SSG/SSR, multiple namespaces, codesplitting, etc.

While next-i18next uses i18next and react-i18next under the hood, users of next-i18next simply need to include their translation content as JSON files and don't have to worry about much else.

A live demo is available here. This demo app is the simple example - nothing more, nothing less.

Why next-i18next?

Easy to set up, easy to use: setup only takes a few steps, and configuration is simple.

No other requirements: next-i18next simplifies internationalisation for your Next.js app without extra dependencies.

Production ready: next-i18next supports passing translations and configuration options into pages as props with SSG/SSR support.

How does it work?

Your next-i18next.config.js file will provide configuration for next-i18next. After configuration, appWithTranslation allows us to use the t (translate) function in our components via hooks.

Then we add serverSideTranslation to getStaticProps or getServerSideProps (depending on your case) in our page-level components.

Now our Next.js app is fully translatable!

Setup

1. Installation

yarn add next-i18next react-i18next i18next

You need to also have react and next installed.

2. Translation content

By default, next-i18next expects your translations to be organised as such:

.
└── public
    └── locales
        ├── en
        |   └── common.json
        └── de
            └── common.json

This structure can also be seen in the simple example.

If you want to structure your translations/namespaces in a custom way, you will need to pass modified localePath and localeStructure values into the initialisation config.

3. Project setup

First, create a next-i18next.config.js file in the root of your project. The syntax for the nested i18n object comes from Next.js directly.

This tells next-i18next what your defaultLocale and other locales are, so that it can preload translations on the server:

next-i18next.config.js

/** @type {import('next-i18next').UserConfig} */
module.exports = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'de'],
  },
}

Now, create or modify your next.config.js file, by passing the i18n object into your next.config.js file, to enable localised URL routing:

next.config.js

const { i18n } = require('./next-i18next.config')

module.exports = {
  i18n,
}

There are three functions that next-i18next exports, which you will need to use to translate your project:

appWithTranslation

This is a HOC which wraps your _app:

import { appWithTranslation } from 'next-i18next'

const MyApp = ({ Component, pageProps }) => (
  <Component {...pageProps} />
)

export default appWithTranslation(MyApp)

The appWithTranslation HOC is primarily responsible for adding a I18nextProvider.

serverSideTranslations

This is an async function that you need to include on your page-level components, via either getStaticProps or getServerSideProps (depending on your use case):

import { serverSideTranslations } from 'next-i18next/serverSideTranslations'

export async function getStaticProps({ locale }) {
  return {
    props: {
      ...(await serverSideTranslations(locale, [
        'common',
        'footer',
      ])),
      // Will be passed to the page component as props
    },
  }
}

Note that serverSideTranslations must be imported from next-i18next/serverSideTranslations – this is a separate module that contains NodeJs-specific code.

Also, note that serverSideTranslations is not compatible with getInitialProps, as it only can execute in a server environment, whereas getInitialProps is called on the client side when navigating between pages.

The serverSideTranslations HOC is primarily responsible for passing translations and configuration options into pages, as props – you need to add it to any page that has translations.

useTranslation

This is the hook which you'll actually use to do the translation itself. The useTranslation hook comes from react-i18next, but needs to be imported from next-i18next directly.
Do NOT use the useTranslation export of react-i18next, but ONLY use the one from next-i18next!

import { useTranslation } from 'next-i18next'

export const Footer = () => {
  const { t } = useTranslation('footer')

  return (
    <footer>
      <p>{t('description')}</p>
    </footer>
  )
}

4. Declaring namespace dependencies

By default, next-i18next will send all your namespaces down to the client on each initial request. This can be an appropriate approach for smaller apps with less content, but a lot of apps will benefit from splitting namespaces based on route.

To do that, you can pass an array of required namespaces for each page into serverSideTranslations. You can see this approach in examples/simple/pages/index.tsx. Passing in an empty array of required namespaces will send no namespaces.

Note: useTranslation provides namespaces to the component that you use it in. However, serverSideTranslations provides the total available namespaces to the entire React tree and belongs on the page level. Both are required.

5. Declaring locale dependencies

By default, next-i18next will send only the active locale down to the client on each request. This helps reduce the size of the initial payload sent to the client. However in some cases one may need the translations for other languages at runtime too. For example when using getFixedT of useTranslation hook.

To change the behavior and load extra locales just pass in an array of locales as the last argument to serverSideTranslations.

  import { serverSideTranslations } from 'next-i18next/serverSideTranslations';

  export async function getStaticProps({ locale }) {
    return {
      props: {
-       ...(await serverSideTranslations(locale, ['common', 'footer'])),
+       ...(await serverSideTranslations(locale, ['common', 'footer'], null, ['en', 'no'])),
      },
    };
  }

As a result the translations for both no and en locales will always be loaded regardless of the current language.

Note: The extra argument should be added to all pages that use getFixedT function.

Fallback locales

By default, next-i18next will add the defaultLocale as fallback. To change this, you can set fallbackLng. All values supported by i18next (string, array, object and function) are supported by next-i18next too.

Additionally nonExplicitSupportedLngs can be set to true to support all variants of a language, without the need to provide JSON files for each of them. Notice that all variants still must be included in locales to enable routing within next.js.

Note: fallbackLng and nonExplicitSupportedLngs can be used at once. There is only one exception: You can not use a function for fallbackLng when nonExplicitSupportedLngs is true,

module.exports = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'fr', 'de-AT', 'de-DE', 'de-CH'],
  },
  fallbackLng: {
    default: ['en'],
    'de-CH': ['fr'],
  },
  nonExplicitSupportedLngs: true,
  // de, fr and en will be loaded as fallback languages for de-CH
}

Be aware that using fallbackLng and nonExplicitSupportedLngs can easily increase the initial size of the page.

fyi: Setting fallbackLng to false will NOT serialize your fallback language (usually defaultLocale). This will decrease the size of your initial page load.

6. Advanced configuration

Passing other config options

If you need to modify more advanced configuration options, you can pass them via next-i18next.config.js. For example:

module.exports = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'de'],
  },
  localePath:
    typeof window === 'undefined'
      ? require('path').resolve('./my-custom/path')
      : '/public/my-custom/path',
  ns: ['common'],
}

Unserializable configs

Some i18next plugins (which you can pass into config.use) are unserializable, as they contain functions and other JavaScript primitives.

You may run into this if your use case is more advanced. You'll see Next.js throw an error like:

Error: Error serializing `._nextI18Next.userConfig.use[0].process` returned from `getStaticProps` in "/my-page".
Reason: `function` cannot be serialized as JSON. Please only return JSON serializable data types.

To fix this, you'll need to set config.serializeConfig to false, and manually pass your config into appWithTranslation:

import { appWithTranslation } from 'next-i18next'
import nextI18NextConfig from '../next-i18next.config.js'

const MyApp = ({ Component, pageProps }) => (
  <Component {...pageProps} />
)

export default appWithTranslation(MyApp, nextI18NextConfig)

import { serverSideTranslations } from 'next-i18next/serverSideTranslations'

import nextI18NextConfig from '../next-i18next.config.js'

export const getStaticProps = async ({ locale }) => ({
  props: {
    ...(await serverSideTranslations(
      locale,
      ['common', 'footer'],
      nextI18NextConfig
    )),
  },
})

Usage with fallback SSG pages

When using on server-side generated pages with getStaticPaths and fallback: true or fallback: 'blocking', the default setup indicated above will cause the app to be unmounted and remounted on every load, causing various adverse consequences like calling every useEffect(() => {...}, []) hook twice and slight performance degradation.

This is due to the fact that, for those pages, Next.js does a first render with empty serverSideProps and then a second render with the serverSideProps that include the next-i18next translations. With the default setup, the i18n instance is initially undefined when serverSideProps is empty, causing the unmount-remount.

To mitigate this issue, you can do the following:

import { UserConfig } from 'next-i18next';
import nextI18NextConfig from '../next-i18next.config.js'

const emptyInitialI18NextConfig: UserConfig = {
  i18n: {
    defaultLocale: nextI18NextConfig.i18n.defaultLocale,
    locales: nextI18NextConfig.i18n.locales,
  },
};

const MyApp = ({ Component, pageProps }) => (
  <Component {...pageProps} />
)

export default appWithTranslation(MyApp, emptyInitialI18NextConfig) // Makes sure the initial i18n instance is not undefined

This will work as long as you make sure that, in the fallback page state, your client-side code is not trying to display any translation since otherwise you will get a "server-client mismatch" error from Next.js (due to the fact that the server has an actual translation in its html while the client html has the translation key in the same place).
This is normal and fine: you shouldn't be displaying a translation key to your user anyway!

Client side loading of translations via HTTP

Since v11.0.0 next-i18next also provides support for client side loading of translations.

In some use cases, you might want to load a translation file dynamically without having to use serverSideTranslations. This can be especially useful for lazy-loaded components that you don't want slowing down pages.

More information about that can be found here.

Reloading Resources in Development

Because resources are loaded once when the server is started, any changes made to your translation JSON files in development will not be loaded until the server is restarted.

In production this does not tend to be an issue, but in development you may want to see updates to your translation JSON files without having to restart your development server each time. To do this, set the reloadOnPrerender config option to true.

This option will reload your translations whenever serverSideTranslations is called (in getStaticProps or getServerSideProps). If you are using serverSideTranslations in getServerSideProps, it is recommended to disable reloadOnPrerender in production environments as to avoid reloading resources on each server call.

Options

localePath as a function is of the form (locale: string, namespace: string, missing: boolean) => string returning the entire path including filename and extension. When missing is true, return the path for the addPath option of i18next-fs-backend, when false, return the path for the loadPath option. More info at the i18next-fs-backend repo.
If the localePath is a function, make sure you also define the ns option, because on server side we're not able to preload the namespaces then.

All other i18next options and react-i18next options can be passed in as well.
You can also pass in the resources directly in combination with setting localePath to null.

Custom interpolation prefix/suffix

By default, i18next uses {{ as prefix and }} as suffix for interpolation. If you want/need to override these interpolation settings, you must also specify an alternative localeStructure setting that matches your custom prefix and suffix.

For example, if you want to use { and } the config would look like this:

{
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'nl'],
  },
  interpolation: {
    prefix: '{',
    suffix: '}',
  },
  localeStructure: '{lng}/{ns}',
}

Custom next-i18next.config.js path

If you want to change the default config path, you can set the environment variable I18NEXT_DEFAULT_CONFIG_PATH.

For example, inside the .env file you can set a static path:

I18NEXT_DEFAULT_CONFIG_PATH=/path/to/project/apps/my-app/next-i18next.config.js

Or you can use a trick for dynamic path and set the following inside next.config.js:

process.env.I18NEXT_DEFAULT_CONFIG_PATH = `${__dirname}/next-i18next.config.js`;

// ... Some other imports

const { i18n } = require('./next-i18next.config');

// ... Some other code

module.exports = {
  i18n,
  ...
};

This means that the i18n configuration file will be in the same directory as next.config.js and it doesn't matter where your current working directory is. This helps for example for nx when you have monorepo and start your application from project root but the application is in apps/{appName}.

Notice If your config next-i18next.config.js is not in the same directory as next.config.js, you must copy it manually (or by custom script).

Adding next-i18next incrementally

If you are planning on incrementally add next-i18next to you project we recommended that you will pass your next-i18next.config to appWithTranslation to avoid any issues.

i.e

import nextI18nextConfig from '../../next-i18next.config';
//...
export default appWithTranslation(MyApp, nextI18nextConfig);

See Issue #2259 for more information.

Notes

Vercel and Netlify

Some serverless PaaS may not be able to locate the path of your translations and require additional configuration. If you have filesystem issues using serverSideTranslations, set config.localePath to use path.resolve. An example can be found here.

Docker

For Docker deployment, note that if you use the Dockerfile from Next.js docs do not forget to copy next.config.js and next-i18next.config.js into the Docker image.

COPY --from=builder /app/next.config.js ./next.config.js
COPY --from=builder /app/next-i18next.config.js ./next-i18next.config.js

Asynchronous i18next backends

If you choose to use an i18next backend different to the built-in i18next-fs-backend, you will need to ensure the translation resources are loaded before you call the t function. Since React suspense is not yet supported for SSR, this can be solved in 2 different ways:

1) Preload the namespaces:

Set the ns option, like in this example. Doing this will ensure all translation resources are loaded on initialization.

2) Check the ready flag:

If you cannot or do not want to provide the ns array, calls to the t function will cause namespaces to be loaded on the fly. This means you'll need to handle the "not ready" state by checking ready === true or props.tReady === true. Not doing so will result in rendering your translations before they loaded, which will cause "save missing" be called despite the translations actually existing (just yet not loaded). This can be done with the useTranslation hook or the withTranslation HOC.

Static HTML Export SSG

Are you trying to generate a static HTML export by executing next export and are getting this error?

Error: i18n support is not compatible with next export. See here for more info on deploying: https://nextjs.org/docs/deployment

But there's a way to workaround that with the help of next-language-detector. Check out this blog post and this example project.

Translate in child components

You have multiple ways to use the t function in your child component:

1. Pass the t function via props down to the children
2. Pass the translated text via props down to the children, like in this example: https://github.com/i18next/next-i18next/blob/master/examples/simple/components/Header.tsx#L12
3. Use the useTranslation function, like in this example: https://github.com/i18next/next-i18next/blob/e6b5085b5e92004afa9516bd444b19b2c8cf5758/examples/simple/components/Footer.tsx#L6
4. Use the withTranslation function

And in general, you always needs to be sure serverSideTranslations contains all namespaces you need in the tree.

Contributors

Thanks goes to these wonderful people (emoji key):

Rob Capellini 💻 ⚠️	Alexander Kachkaev 📢 💬 🤔 💻 ⚠️	Mathias Wøbbe 💻 🤔 ⚠️	Lucas Feliciano 🤔 👀	Ryan Leung 💻	Nathan Friemel 💻 📖 💡 🤔	Isaac Hinman ️️️️♿️ 💬 🔊 📝 🐛 💼 💻 🖋 🔣 🎨 📖 📋 💡 💵 🔍 🤔 🚇 🚧 🧑‍🏫 📦 🔌 📆 🔬 👀 🛡️ 📢 ⚠️ 🔧 🌍 ✅ 📓 📹
Adriano Raiano ️️️️♿️ 💬 🔊 📝 🐛 💼 💻 🖋 🔣 🎨 📖 📋 💡 💵 🔍 🤔 🚇 🚧 🧑‍🏫 📦 🔌 📆 🔬 👀 🛡️ 📢 ⚠️ 🔧 🌍 ✅ 📓 📹	Felix Mosheev 💬 💻 📢 ⚠️	Sébastien Vanvelthem 💻 📖 💡 🚧 📓

This project follows the all-contributors specification. Contributions of any kind welcome!

Gold Sponsors

localization as a service - locize.com

Needing a translation management? Want to edit your translations with an InContext Editor? Use the original provided to you by the maintainers of i18next!

With using locize you directly support the future of i18next and next-i18next.

15.4.2

• types: re-add @types/hoist-non-react-statics to dependencies #2316

15.4.1

• Move @types/hoist-non-react-statics to devDependencies #2310

15.4.0

• support i18next v24

15.3.1

• update some i18next dependencies to address #2288

15.3.0

• Only overwrite ns config if it provided #2270

15.2.0

• add possibility to pass resources directly via config and set localePath to null

15.1.2

• fix: Install error with react-i18next v14 #2248

15.1.1

• optimize/fix last change for turbo

15.1.0

• try to fix for turbo #2222

15.0.0

• refactor: reuse existing i18next instance #2226 -> If you use client side pages (not lazy loading translations), like described here, make sure you set the partialBundledLanguages option to true, like here.

14.0.3

• fix: correct namespacesRequired type in serverSideTranslations #2203

14.0.2

• try to fix namespacesRequired in serverSideTranslations is not type-safe anymore #2201

14.0.0

• requires i18next >= v23.0.1
• requires react-i18next >= v13.0.0

Breaking changes

i18next 23.0.0 dropped support for older browsers. From nextjs 13, you can use the transpilePackages to avoid issues.

/** @type {import('next').NextConfig} */
const nextConfig = {
  transpilePackages: ['i18next'],
}
module.exports = nextConfig

13.3.0

• using a custom backend on server side should also lazy load the passed namespaces

13.2.2

• pageProps may be undefined on strange setups #2109"

13.2.1

• types: fix serverSideTranslations args #2104"

13.2.0

• types: Update serverSideTranslation args type #2097"

13.1.6

• fix: allow user provided affixes to be used without providing localeStructure #2100"

13.1.5

• #2089, more stable impelementation of "feat(server-side): custom default config path #2084"

13.1.4

• revert #2084

13.1.3

• another code snippet for #2084 to try to fix for dynamic pages

13.1.2

• different code snippet for #2084 to try to fix for dynamic pages

13.1.1

• log config path if no config found

13.1.0

• feat(server-side): custom default config path #2084

13.0.3

• Error if custom localeStructure provided, but no ns option defined.

13.0.2

Fix

• Types: DefaultNamespace import, see #2061.

13.0.1

Fix

• Fix missing i18n.localeDetection in UserConfig, see #2057.
• Update examples to latest i18next in #2058

Caution

If you're experiencing typecheck errors regarding keys: ensure i18next is at least ^22.4.3 in your package.json (then run install), see #2058.

13.0.0

The v13.0.0 release is a major version to improve stability and general experience. It comes with 2 easy changes related to installation. Existing code shouldn't be impacted. Details can be found in the UPGRADING.md document.

Breaking changes

• react-i18next and i18next have been moved to peer-dependencies. They must be installed in your app (#1966)

  # Add react-i18next > 12.0.0 and i18next > 22.0.4 to your app dependencies
  npm install react-i18next i18next --save  # NPM
  yarn add react-i18next i18next            # Yarn
  pnpm add react-i18next i18next --save     # PNPM

  This might solve issues with duplicates and multiple i18n context instances. If you encounter any issue, please read the Troubleshoot doc before posting an issue.

• Types augmentations are now handled by i18next instead of react-i18next (#1997). See the upgrade document here.

New

• Support for NextJs 13 (excluding new experimental layout / rsc)
• Upgrade to i18next v22 and react-i18next v12, see #1966
• Support for node 18 lts #2017

Fix

• Fix types for appWithTranslation #1987

New minimum versions

We've dropped support for nextjs < 12.0.0 / react < 17.0.2 (#1983) and node < 14 (#1974).

12.1.0

• fix: appWithTranslation re-renders _app when the locale is changed (#1954)
• feat: introduce onPreInitI18next option (#1960)

12.0.1

• fix: fallbackLng if namespaces are undefined (#1943 closes #1941)

12.0.0

Why a major version? The following changes could lead to more languages being loaded, which could increase the page size.

• feat: improve fallback language handling (#1927)
• feat: add support for nonExplicitSupportedLngs (#1930)

11.3.0

• feat: introduce extraLocales (#1916)

11.2.2

• fix: pass namespaces to the client also for custom backends (#1913)

11.2.1

• fix: pass namespaces to the client (#1912 closes #1839)

11.2.0

• feat: support nested namespace structure (#1911)

11.1.1

• fix: remove postinstall script

11.1.0

• first release with new project ownership
• update most dependencies
• update docs and example
• feat: support default locale by ignoring it (#1679)

11.0.0

Features:

• Allow client side translation loading (8132efd)

Documentation:

• Link to react-i18next config options (422a0f3)