next-i18next


The easiest way to translate your NextJs apps.

What is this?

next-i18next is a plugin for Next.js projects that allows you to get translations up and running quickly and easily, while fully supporting SSR, multiple namespaces with 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. Please be aware this is hosted on a free Heroku dyno and therefore may go to sleep during periods of inactivity. This demo app is the simple example - nothing more, nothing less.

Setup

$3

``jsx
yarn add next-i18next
`

You need to also have react and next installed.

$3

By default, next-i18next expects your translations to be organised as such:
`
.
└── static
└── 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

The default export of next-i18next is a class constructor, into which you pass your config options. The resulting class has all the methods you will need to translate your app:

`jsx
import NextI18Next from 'next-i18next'

const NextI18NextInstance = new NextI18Next({
defaultLanguage: 'en',
otherLanguages: ['de']
})

export default NextI18NextInstance

/ Optionally, export class methods as named exports /
export const {
appWithTranslation,
withTranslation,
} = NextI18NextInstance
`

A full list of options can be seen here.

It's recommended to export this NextI18Next instance from a single file in your project, where you can continually import it from to use the class methods as needed. You can see this approach in the examples/simple/i18n.js file.

After creating and exporting your NextI18Next instance, you need to take the following steps to get things working:

1. Create an _app.js file inside your pages directory, and wrap it with the NextI18Next.appWithTranslation higher order component (HOC). You can see this approach in the examples/simple/pages/_app.js.
2. Create a server.js file inside your root directory, initialise an express server, and use the nextI18NextMiddleware middleware with your nextI18Next instance passed in. You can see this approach in the examples/simple/server.js. For more info, see the NextJs section on custom servers.

That's it! Your app is ready to go. You can now use the NextI18Next.withTranslation HOC to make your components or pages translatable, based on namespaces:

`jsx
import React from 'react'

// This is our initialised NextI18Next instance
import { withTranslation } from '../i18n'

class Footer extends React.Component {
render() {
return (


)
}
}

export default withTranslation('footer')(Footer)
`

$3

The withTranslation HOC is responsible for passing the t function to your component. It enables all the translation functionality provided by i18next. Further, it asserts your component gets re-rendered on language change or changes to the translation catalog itself (loaded translations). More info can be found here.

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 need to return a namespacesRequired array via getInitialProps on your page-level component. You can see this approach in examples/simple/pages/index.js.

Note: withTranslation provides namespaces to the component that it wraps. However, namespacesRequired provides the total available namespaces to the entire React tree and belongs on the page level. Both are required (although you can use Trans instead of withTranslation if desired).

$3

One of the main features of this package, besides translation itself, are locale subpaths. It's easiest to explain by example:

`
myapp.com ---> Homepage in default lang
myapp.com/de ---> Homepage in German
`

This functionality is not enabled by default, and must be passed as an option into the NextI18Next constructor as a config option:

`jsx
new NextI18Next({
localeSubpaths: {
de: 'de'
}
})
`

The localeSubpaths option is a key/value mapping, where keys are the locale itself (case sensitive) and values are the subpath without slashes.

Now, all your page routes will be duplicated across all your locale subpaths. Here's an example:

`jsx
----- Config -----
new NextI18Next({
localeSubpaths: {
fr: 'fr',
de: 'german',
en: 'eng',
}
})

----- Output -----
myapp.com/fr
myapp.com/german
myapp.com/eng
`

When using the localeSubpaths option, our middleware may redirect without calling any subsequent middleware. Therefore, if there are any critical middleware that must run before this redirect, ensure that you place it before the nextI18NextMiddleware middleware.

The main "gotcha" with locale subpaths is routing. We want to be able to route to "naked" routes, and not have to worry about the locale subpath part of the route:

`jsx

`

With this link, we would expect someone whose language is set to French to automatically be directed to /fr/some-page.

To do that, we must import Link from your NextI18Next instance, not next/router:

`jsx
import React from 'react'

// This is our initialised NextI18Next instance
import { Link } from '../i18n'

const SomeLink = () => (

This will magically prepend locale subpaths

)
`

We can also navigate imperatively with locale subpaths by importing Router from your NextI18Next instance.
The exported Router shares the same API as the native Next Router. The push, replace, and prefetch functions will automatically prepend locale subpaths.

`jsx
import React from 'react'

// This is our initialised NextI18Next instance
import { Router } from '../i18n'

const SomeButton = () => (
onClick={() => Router.push('/some-page')}
>
This will magically prepend locale subpaths

)
`

Custom Routing

Custom routing can be achieved via the app.render method:

`jsx
/ First, use middleware /
server.use(nextI18NextMiddleware(nextI18next))

/ Second, declare custom routes /
server.get('/products/:id', (req, res) => {
const { query, params } = req

return app.render(req, res, '/product-page', { ...query, id: params.id })
})

/ Third, add catch-all GET for non-custom routes /
server.get('*', (req, res) => handle(req, res))
`

Accessing the Current Language

In many cases, you'll need to know the currently active language. Most of the time, to accomplish this, you should use the withTranslation HOC, which will pass an i18n prop to the wrapped component and further asserts your component will get re-rendered on language change or changes to the translation catalog itself (loaded translations). More info can be found here.

If for some reason you need to access the current language inside getInitialProps, you'll need to switch over server and client contexts. For example:

`jsx
// This is our initialised NextI18Next instance
import { i18n } from '../i18n'

MyPage.getInitialProps = async({ req }) => {
const currentLanguage = req ? req.language : i18n.language
}
`

Options

| Key | Default value |
| ------------- | ------------- |
| browserLanguageDetection | true |
| defaultNS | 'common' |
| defaultLanguage | 'en' |
| ignoreRoutes | ['/_next/', '/static/'] |
| otherLanguages (required) | [] |
| localeExtension | 'json' |
| localePath | 'static/locales' |
| localeStructure | '{{lng}}/{{ns}}' |
| localeSubpaths | {} |
| serverLanguageDetection | true |
| strictMode | true |
| use (for plugins) | [] |
| customDetectors | [] |

_This table contains options which are specific to next-i18next. All other i18next options can be passed in as well._

Notes

- next export will result in a _client-side only_ React application.
- We cannot support koa until a 1:1 replacement for i18next-express-middleware exists.
- Serverless (e.g. Now 2.0) is not currently supported.
- To add a lang attribute to your top-level html DOM node, you must create a _document.js file.
- Localising next/head requires special consideration due to NextJs internals.
- Support for browsers (e.g IE11/Edge) with limited support for modern ES6/7 features may require polyfills until #290` is resolved.

Contributors

Thanks goes to these wonderful people (emoji key):

Rob Capellini 💻 ⚠️

Alexander Kachkaev 📢 💬 🤔 💻 ⚠️

Mathias Wøbbe 💻 🤔 ⚠️

Lucas Feliciano 🤔 👀

Ryan Leung 💻

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

Supported by BrowserStack

Thanks to BrowserStack for their support of this open-source project.