JavaScripting

The definitive source of the best
JavaScript libraries, frameworks, and plugins.

  • ×

    Next Translate

    Github

    Next.js plugin + i18n API for Next.js 🌍 - Load page translations and use them in an easy way!
    Filed under 

    • 🔾62%Overall
    • ★2,175
    • ⏳4.3 days
    • 🕩185
    • 👥17

    next-translate

    Easy i18n for Next.js +10

    Next plugin + i18n API

    Translations in prerendered pages

    1. About next-translate

    The main goal of this library is to keep the translations as simple as possible in a Next.js environment.

    Next-translate has two parts: Next.js plugin + i18n API.

    Features ✨

    • 🚀 ・ Automatic page optimization (pages dir).
    • 🏝️ ・ React 18 server/client pages/components (app dir).
    • 🦄 ・ Easy to use and configure.
    • 🌍 ・ Basic i18n support: interpolation, plurals, useTranslation hook, Trans component...
    • 🈂️ ・ It loads only the necessary translations (for page and for locale).
    • 📦 ・ Tiny (~1kb) and tree shakable. No dependencies.

    Bundle size

    How are translations loaded?

    In the configuration file, you specify each page that namespaces needs:

    i18n.json

    {
  "pages": {
    "*": ["common"],
    "/": ["home"],
    "/cart": ["cart"],
    "/content/[slug]": ["content"],
    "rgx:^/account": ["account"]
  }
  // rest of config here...
}

    Read here about how to add the namespaces JSON files.

    Next-translate ensures that each page only has its namespaces with the current language. So if we have 100 locales, only 1 will be loaded.

    In order to do this we use a webpack loader that loads the necessary translation files inside the Next.js methods (getStaticProps, getServerSideProps or getInitialProps). If you have one of these methods already on your page, the webpack loader will use your own method, but the defaults it will use are:

    • getStaticProps. This is the default method used on most pages, unless it is a page specified in the next two points. This is for performance, so the calculations are done in build time instead of request time.
    • getServerSideProps. This is the default method for dynamic pages like [slug].js or [...catchall].js. This is because for these pages it is necessary to define the getStaticPaths and there is no knowledge of how the slugs should be for each locale. Likewise, how is it by default, only that you write the getStaticPaths then it will already use the getStaticProps to load the translations.
    • getInitialProps. This is the default method for these pages that use a HoC. This is in order to avoid conflicts because HoC could overwrite a getInitialProps.

    This whole process is transparent, so in your pages you can directly consume the useTranslate hook to use the namespaces, and you don't need to do anything else.

    If for some reason you use a getInitialProps in your _app.js file, then the translations will only be loaded into your getInitialProps from _app.js. We recommend that for optimization reasons you don't use this approach unless it is absolutely necessary.

    2. Getting started

    Install

    • yarn add next-translate

    Add next-translate plugin

    The next-translate-plugin is a tool that allows developers to efficiently handle translations on a page-by-page basis during the build process. It is distinct from the next-translate package, which allows developers to access the translations in the code where it is needed. The plugin works by parsing all pages, searching for the translations and rewriting the page file adding the translations to it. This makes the plugin a more efficient and flexible solution for handling translations within a Next.js application. It is recommended to install the plugin as a devDependency.

    • yarn add next-translate-plugin -D

    In your next.config.js file:

    const nextTranslate = require('next-translate-plugin')

module.exports = nextTranslate()

    Or if you already have next.config.js file and want to keep the changes in it, pass the config object to the nextTranslate(). For example for webpack you could do it like this:

    const nextTranslate = require('next-translate-plugin')

module.exports = nextTranslate({
  webpack: (config, { isServer, webpack }) => {
    return config;
  }
})

    Add i18n.js config file

    Add a configuration file i18n.json (or i18n.js with module.exports) in the root of the project. Each page should have its namespaces. Take a look at it in the config section for more details.

    {
  "locales": ["en", "ca", "es"],
  "defaultLocale": "en",
  "pages": {
    "*": ["common"],
    "/": ["home", "example"],
    "/about": ["about"]
  }
}

    In the configuration file you can use both the configuration that we specified here and the own features about internationalization of Next.js 10.

    Create your namespaces files

    By default the namespaces are specified on the /locales root directory in this way:

    /locales

    .
├── ca
│   ├── common.json
│   └── home.json
├── en
│   ├── common.json
│   └── home.json
└── es
    ├── common.json
    └── home.json

    Each filename matches the namespace specified on the pages config property, while each file content should be similar to this:

    {
  "title": "Hello world",
  "variable-example": "Using a variable {{count}}"
}

    However, you can use another destination to save your namespaces files using loadLocaleFrom configuration property:

    i18n.js

    {
  // ...rest of config
  "loadLocaleFrom": (lang, ns) =>
    // You can use a dynamic import, fetch, whatever. You should
    // return a Promise with the JSON file.
    import(`./myTranslationsFiles/${lang}/${ns}.json`).then((m) => m.default),
}

    Use translations in your pages

    Then, use the translations in the page and its components:

    pages/example.js

    import useTranslation from 'next-translate/useTranslation'

export default function ExamplePage() {
  const { t, lang } = useTranslation('common')
  const example = t('variable-example', { count: 42 })

  return <div>{example}</div> // <div>Using a variable 42</div>
}

    You can consume the translations directly on your pages, you don't have to worry about loading the namespaces files manually on each page. The next-translate plugin loads only the namespaces that the page needs and only with the current language.

    3. Configuration

    In the configuration file you can use both the configuration that we specified here and the own features about internationalization of Next.js 10.

    Option Description Type Default
    defaultLocale ISO of the default locale ("en" as default). string "en"
    locales An array with all the languages to use in the project. string[] []
    loadLocaleFrom Change the way you load the namespaces. function that returns a Promise with the JSON. By default is loading the namespaces from locales root directory.
    pages An object that defines the namespaces used in each page. Example of object: {"/": ["home", "example"]}. To add namespaces to all pages you should use the key "*", ex: {"*": ["common"]}. It's also possible to use regex using rgx: on front: {"rgx:/form$": ["form"]}. You can also use a function instead of an array, to provide some namespaces depending on some rules, ex: { "/": ({ req, query }) => query.type === 'example' ? ['example'] : []} Object<string[] or function> {}
    logger Function to log the missing keys in development and production. If you are using i18n.json as config file you should change it to i18n.js. function By default the logger is a function doing a console.warn only in development.
    loggerEnvironment String to define if the logger should run in the browser, in node or both "node" | "browser" | "both" "browser"
    logBuild Each page has a log indicating: namespaces, current language and method used to load the namespaces. With this you can disable it. Boolean true
    loader If you wish to disable the webpack loader and manually load the namespaces on each page, we give you the opportunity to do so by disabling this option. Boolean true
    interpolation Change the delimiter that is used for interpolation. {prefix: string; suffix: string, formatter: function } {prefix: '{{', suffix: '}}'}
    keySeparator Change the separator that is used for nested keys. Set to false to disable keys nesting in JSON translation files. Can be useful if you want to use natural text as keys. string | false '.'
    nsSeparator char to split namespace from key. You should set it to false if you want to use natural text as keys. string | false ':'
    defaultNS default namespace used if not passed to useTranslation or in the translation key. string undefined
    staticsHoc The HOCs we have in our API (appWithI18n), do not use hoist-non-react-statics in order not to include more kb than necessary (static values different than getInitialProps in the pages are rarely used). If you have any conflict with statics, you can add hoist-non-react-statics (or any other alternative) here. See an example. Function null
    extensionsRgx Change the regex used by the webpack loader to find Next.js pages. Regex `/.(tsx\ ts\ js\ mjs\ jsx)$/`
    revalidate If you want to have a default revalidate on each page we give you the opportunity to do so by passing a number to revalidate. You can still define getStaticProps on a page with a different revalidate amount and override this default override. Number If you don't define it, by default the pages will have no revalidate.
    pagesInDir If you run next ./my-app to change where your pages are, you can here define my-app/pages so that next-translate can guess where they are. String If you don't define it, by default the pages will be searched for in the classic places like pages and src/pages.
    localesToIgnore Indicate these locales to ignore when you are prefixing the default locale using a middleware (in Next +12, learn how to do it) Array<string> ['default']
    allowEmptyStrings Change how translated empty strings should be handled. If omitted or passed as true, it returns an empty string. If passed as false, returns the key name itself (including ns). Boolean true

    4. API

    useTranslation

    Size: ~150b 📦

    This hook is the recommended way to use translations in your pages / components.

    • Input: string - defaultNamespace (optional)
    • Output: Object { t: Function, lang: string }

    Example:

    import React from 'react'
import useTranslation from 'next-translate/useTranslation'

export default function Description() {
  const { t, lang } = useTranslation('ns1') // default namespace (optional)
  const title = t('title')
  const titleFromOtherNamespace = t('ns2:title')
  const description = t`description` // also works as template string
  const example = t('ns2:example', { count: 3 }) // and with query params
  const exampleDefault = t('ns:example', { count: 3 }, { default: "The count is: {{count}}." }) // and with default translation

  return (
    <>
      <h1>{title}</h1>
      <p>{description}</p>
      <p>{example}</p>
    <>
  )
}

    The t function:

    • Input:
      • i18nKey: string (namespace:key)
      • query: Object (optional) (example: { name: 'Leonard' })
      • options: Object (optional)
        • fallback: string | string[] - fallback if i18nKey doesn't exist. See more.
        • returnObjects: boolean - Get part of the JSON with all the translations. See more.
        • default: string - Default translation for the key. If fallback keys are used, it will be used only after exhausting all the fallbacks.
        • ns: string - Namespace to use when none is embded in the i18nKey.
    • Output: string

    withTranslation

    Size: ~560b 📦

    It's an alternative to useTranslation hook, but in a HOC for these components that are no-functional. (Not recommended, it's better to use the useTranslation hook.).

    The withTranslation HOC returns a Component with an extra prop named i18n (Object { t: Function, lang: string }).

    Example:

    import React from 'react'
import withTranslation from 'next-translate/withTranslation'

class Description extends React.Component {
  render() {
    const { t, lang } = this.props.i18n
    const description = t('common:description')

    return <p>{description}</p>
  }
}

export default withTranslation(NoFunctionalComponent)

    Similar to useTranslation("common") you can call withTranslation with the second parameter defining a default namespace to use:

    export default withTranslation(NoFunctionalComponent, "common")

    Trans Component

    Size: ~1.4kb 📦

    Sometimes we need to do some translations with HTML inside the text (bolds, links, etc), the Trans component is exactly what you need for this. We recommend to use this component only in this case, for other cases we highly recommend the usage of useTranslation hook instead.

    Example:

    // The defined dictionary entry is like:
// "example": "<0>The number is <1>{{count}}</1></0>",
<Trans
  i18nKey="common:example"
  components={[<Component />, <b className="red" />]}
  values={{ count: 42 }}
/>

    Or using components prop as a object:

    // The defined dictionary entry is like:
// "example": "<component>The number is <b>{{count}}</b></component>",
<Trans
  i18nKey="common:example"
  components={{
    component: <Component />,
    b: <b className="red" />,
  }}
  values={{ count: 42 }}
  defaultTrans="<component>The number is <b>{{count}}</b></component>"
/>
    • Props:
      • i18nKey - string - key of i18n entry (namespace:key)
      • components - Array | Object - In case of Array each index corresponds to the defined tag <0>/<1>. In case of object each key corresponds to the defined tag <example>.
      • values - Object - query params
      • fallback - string | string[] - Optional. Fallback i18nKey if the i18nKey doesn't match.
      • defaultTrans - string - Default translation for the key. If fallback keys are used, it will be used only after exhausting all the fallbacks.
      • ns - Namespace to use when none is embedded in i18nKey

    In cases where we require the functionality of the Trans component, but need a string to be interpolated, rather than the output of the t(props.i18nKey) function, there is also a TransText component, which takes a text prop instead of i18nKey.

    • Props:
      • text - string - The string which (optionally) contains tags requiring interpolation
      • components - Array | Object - This behaves exactly the same as Trans (see above).

    This is especially useful when mapping over the output of a t() with returnObjects: true:

    // The defined dictionary entry is like:
// "content-list": ["List of <link>things</link>", "with <em>tags</em>"]
const contentList = t('someNamespace:content-list', {}, { returnObjects: true });

{contentList.map((listItem: string) => (
  <TransText
    text={listItem}
    components={{
      link: <a href="some-url" />,
      em: <em />,
    }}
  />
)}

    DynamicNamespaces

    Size: ~1.5kb 📦

    The DynamicNamespaces component is useful to load dynamic namespaces, for example, in modals.

    Example:

    import React from 'react'
import Trans from 'next-translate/Trans'
import DynamicNamespaces from 'next-translate/DynamicNamespaces'

export default function ExampleWithDynamicNamespace() {
  return (
    <DynamicNamespaces namespaces={['dynamic']} fallback="Loading...">
      {/* ALSO IS POSSIBLE TO USE NAMESPACES FROM THE PAGE */}
      <h1>
        <Trans i18nKey="common:title" />
      </h1>

      {/* USING DYNAMIC NAMESPACE */}
      <Trans i18nKey="dynamic:example-of-dynamic-translation" />
    </DynamicNamespaces>
  )
}

    Remember that ['dynamic'] namespace should not be listed on pages configuration:

     pages: {
    '/my-page': ['common'], // only common namespace
  }
    • Props:
      • namespaces - string[] - list of dynamic namespaces to download - Required.
      • fallback- ReactNode - Fallback to display meanwhile the namespaces are loading. - Optional.
      • dynamic - function - By default it uses the loadLocaleFrom in the configuration to load the namespaces, but you can specify another destination. - Optional.

    getT

    Size: ~1.3kb 📦

    Asynchronous function to load the t function outside components / pages. It works on both server-side and client-side.

    Unlike the useTranslation hook, we can use here any namespace, it doesn't have to be a namespace defined in the "pages" configuration. It downloads the namespace indicated as a parameter on runtime.
    You can load multiple namespaces by giving an array as a parameter, in this case the default namespace will be the fist one.

    Example inside getStaticProps:

    import getT from 'next-translate/getT'
// ...
export async function getStaticProps({ locale }) {
  const t = await getT(locale, 'common')
  const title = t('title')
  return { props: { title } }
}

    Example inside API Route:

    import getT from 'next-translate/getT'

export default async function handler(req, res) {
  const t = await getT(req.query.__nextLocale, 'common')
  const title = t('title')

  res.statusCode = 200
  res.setHeader('Content-Type', 'application/json')
  res.end(JSON.stringify({ title }))
}

    Example of loading multiple namespaces:

    import getT from 'next-translate/getT'

export default async function handler(req, res) {
  const t = await getT(req.query.__nextLocale, ['common', 'errors'])
  const title = t('title') // The default namespace is the first one.
  const errorMessage = t('errors:app_error') // The default namespace is the first one.

  res.statusCode = 200
  res.setHeader('Content-Type', 'application/json')
  res.end(JSON.stringify({ title }))
}

    I18nProvider

    Size: ~3kb 📦

    The I18nProvider is a context provider internally used by next-translate to provide the current lang and the page namespaces. SO MAYBE YOU'LL NEVER NEED THIS.

    However, it's exposed to the API because it can be useful in some cases. For example, to use multi-language translations in a page.

    The I18nProvider is accumulating the namespaces, so you can rename the new ones in order to keep the old ones.

    import React from 'react'
import I18nProvider from 'next-translate/I18nProvider'
import useTranslation from 'next-translate/useTranslation'

// Import English common.json
import commonEN from '../../locales/en/common.json'

function PageContent() {
  const { t, lang } = useTranslation()

  console.log(lang) // -> current language

  return (
    <div>
      <p>{t('common:example') /* Current language */}</p>
      <p>{t('commonEN:example') /* Force English */}</p>
    </div>
  )
}

export default function Page() {
  const { lang } = useTranslation()

  return (
    <I18nProvider lang={lang} namespaces={{ commonEN }}>
      <PageContent />
    </I18nProvider>
  )
}

    appWithI18n

    Size: ~3.7kb 📦

    The appWithI18n is internally used by next-translate. SO MAYBE YOU'LL NEVER NEED THIS. However, we expose it in the API in case you disable the webpack loader option and decide to load the namespaces manually.

    If you wish not to use the webpack loader, then you should put this in your _app.js file (and create the _app.js file if you don't have it).

    Example:

    _app.js

    import appWithI18n from 'next-translate/appWithI18n'
import i18nConfig from '../i18n'

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}

// Wrapping your _app.js
export default appWithI18n(MyApp, {
  ...i18nConfig,
  // Set to false if you want to load all the namespaces on _app.js getInitialProps
  skipInitialProps: true,
})

    If skipInitialProps=true, then you should also use the loadNamespaces helper to manually load the namespaces on each page.

    loadNamespaces

    Size: ~1.9kb 📦

    The loadNamespaces is internally used by next-translate. SO MAYBE YOU'LL NEVER NEED THIS. However, we expose it in the API in case you disable the webpack loader option and decide to load the namespaces manually.

    To load the namespaces, you must return in your pages the props that the helper provides.

    import loadNamespaces from 'next-translate/loadNamespaces'

export function getStaticProps({ locale }) {
  return {
    props: {
      ...(await loadNamespaces({ locale, pathname: '/about' })),
    }
  }
}

    🚨 To work well, it is necessary that your _app.js will be wrapped with the appWithI18n. Also, the loadLocaleFrom configuration property is mandatory to define it.

    5. Plurals

    We support 6 plural forms (taken from CLDR Plurals page) by adding to the key this suffix (or nesting it under the key with no _ prefix):

    • _zero
    • _one (singular)
    • _two (dual)
    • _few (paucal)
    • _many (also used for fractions if they have a separate class)
    • _other (required—general plural form—also used if the language only has a single form)

    _See more info about plurals here_.

    Only the last one, _other, is required because it’s the only common plural form used in all locales.

    All other plural forms depends on locale. For example English has only two: _one and _other (1 cat vs. 2 cats). Some languages have more, like Russian and Arabic.

    In addition, we also support an exact match by specifying the number (_0, _999) and this works for all locales. Here is an example:

    Code:

    // **Note**: Only works if the name of the variable is {{count}}.
t('cart-message', { count })

    Namespace:

    {
  "cart-message_0": "The cart is empty", // when count === 0
  "cart-message_one": "The cart has only {{count}} product", // singular
  "cart-message_other": "The cart has {{count}} products", // plural
  "cart-message_999": "The cart is full", // when count === 999
}

    or

    {
  "cart-message": {
     "0": "The cart is empty", // when count === 0
     "one": "The cart has only {{count}} product", // singular
     "other": "The cart has {{count}} products", // plural
     "999": "The cart is full", // when count === 999
  }
}

    Intl.PluralRules API is only available for modern browsers, if you want to use it in legacy browsers you should add a polyfill.

    6. Use HTML inside the translation

    You can define HTML inside the translation this way:

    {
  "example-with-html": "<0>This is an example <1>using HTML</1> inside the translation</0>"
}

    Example:

    import Trans from 'next-translate/Trans'
// ...
const Component = (props) => <p {...props} />
// ...
<Trans
  i18nKey="namespace:example-with-html"
  components={[<Component />, <b className="red" />]}
/>

    Rendered result:

    <p>This is an example <b class="red">using HTML</b> inside the translation</p>

    Each index of components array corresponds with <index></index> of the definition.

    In the components array, it's not necessary to pass the children of each element. Children will be calculated.

    7. Nested translations

    In the namespace, it's possible to define nested keys like this:

    {
  "nested-example": {
    "very-nested": {
      "nested": "Nested example!"
    }
  }
}

    In order to use it, you should use "." as id separator:

    t`namespace:nested-example.very-nested.nested`

    Also is possible to use as array:

    {
  "array-example": [
    { "example": "Example {{count}}" },
    { "another-example": "Another example {{count}}" }
  ]
}

    And get all the array translations with the option returnObjects:

    t('namespace:array-example', { count: 1 }, { returnObjects: true })
/*
[
  { "example": "Example 1" },
  { "another-example": "Another example 1" }
]
*/

    Also it is possible to get all the translations by using the keySeparator as the key, default is '.' : 

    t('namespace:.', { count: 1 }, { returnObjects: true })
/*
{
  "array-example": [
    { "example": "Example 1" },
    { "another-example": "Another example 1" }
  ]
}
*/

    8. Fallbacks

    If no translation exists you can define fallbacks (string|string[]) to search for other translations:

    const { t } = useTranslation()
const textOrFallback = t(
  'ns:text',
  { count: 1 },
  {
    fallback: 'ns:fallback',
  }
)

    List of fallbacks:

    const { t } = useTranslation()
const textOrFallback = t(
  'ns:text',
  { count: 42 },
  {
    fallback: ['ns:fallback1', 'ns:fallback2'],
  }
)

    In Trans Component:

    <Trans
  i18nKey="ns:example"
  components={[<Component />, <b className="red" />]}
  values={{ count: 42 }}
  fallback={['ns:fallback1', 'ns:fallback2']} // or string with just 1 fallback
/>

    9. Formatter

    You can format params using the interpolation.formatter config function.

    in i18n.js:

    const formatters = {
  es: new Intl.NumberFormat("es-ES"),
  en: new Intl.NumberFormat("en-EN"),
}

return {
  // ...
  interpolation: {
    format: (value, format, lang) => {
      if(format === 'number') return formatters[lang].format(value)
      return value
    }
  }
}

    In English namespace:

    {
  "example": "The number is {{count, number}}"
}

    In Spanish namespace:

    {
  "example": "El número es {{count, number}}"
}

    Using:

    t('example', { count: 33.5 })

    Returns:

    • In English: The number is 33.5
    • In Spanish: El número es 33,5

    10. How to change the language

    In order to change the current language you can use the Next.js navigation (Link and Router) passing the locale prop.

    An example of a possible ChangeLanguage component using the useRouter hook from Next.js:

    import React from 'react'
import Link from 'next/link'
import useTranslation from 'next-translate/useTranslation'
import i18nConfig from '../i18n.json'

const { locales } = i18nConfig

export default function ChangeLanguage() {
  const { t, lang } = useTranslation()

  return locales.map((lng) => {
    if (lng === lang) return null

    return (
      <Link href="/" locale={lng} key={lng}>
        {t(`layout:language-name-${lng}`)}
      </Link>
    )
  })
}

    You could also use setLanguage to change the language while keeping the same page.

    import React from 'react'
import setLanguage from 'next-translate/setLanguage'

export default function ChangeLanguage() {
  return (
    <button onClick={async () => await setLanguage('en')}>EN</button>
  )
}

    Another way of accessing the locales list to change the language is using the Next.js router. The locales list can be accessed using the Next.js useRouter hook.

    11. How to save the user-defined language

    You can set a cookie named NEXT_LOCALE with the user-defined language as value, this way a locale can be forced.

    Example of hook:

    import { useRouter } from 'next/router'

// ...

function usePersistLocaleCookie() {
    const { locale, defaultLocale } = useRouter()

    useEffect(persistLocaleCookie, [locale, defaultLocale])
    function persistLocaleCookie() {
      if(locale !== defaultLocale) {
         const date = new Date()
         const expireMs = 100 * 24 * 60 * 60 * 1000 // 100 days
         date.setTime(date.getTime() + expireMs)
         document.cookie = `NEXT_LOCALE=${locale};expires=${date.toUTCString()};path=/`
      }
    }
}

    12. How to use multi-language in a page

    In some cases, when the page is in the current language, you may want to do some exceptions displaying some text in another language.

    In this case, you can achieve this by using the I18nProvider.

    Learn how to do it here.

    13. How to use next-translate in a mono-repo

    Next-translate uses by default the current working directory of the Node.js process (process.cwd()).

    If you want to change it you can use :

    • the NEXT_TRANSLATE_PATH environment variable. It supports both relative and absolute path
    • the native NodeJS function process.chdir(PATH_TO_NEXT_TRANSLATE) to move the process.cwd()

    14. Use Next 13 app directory

    When it comes to server components and client components, it can be challenging to load the same thing on different pages. To simplify this process, we have extracted all the complexity using the next-translate-plugin.

    If you're interested in learning more about how Next-translate works with the new Next.js 13 app dir paradigm, check out this article for a detailed explanation.

    Regarding translations:

    If you use the "app" folder instead of the "pages" folder, the next-translate-plugin will automatically detect the change, and you won't need to touch any of the Next-translate configuration. The only difference is that the "pages" configuration property will reference the pages located within the "app" folder.

    i18n.js

    module.exports = {
  locales: ['en', 'ca', 'es'],
  defaultLocale: 'en',
  pages: {
    '*': ['common'],
    '/': ['home'], // app/page.tsx
    '/second-page': ['home'], // app/second-page/page.tsx
  },
}

    By simply changing the "pages" folder to "app," you can consume translations within your pages using the useTranslation hook or the Trans component. You will still see the log (if enabled) to know which namespaces are loaded on each page, and everything else should be the same.

    🌊 Server page/component (+0kb): app/page.js:

    import useTranslation from 'next-translate/useTranslation'

export default function HomePage() {
  const { t, lang } = useTranslation('home')

  return <h1>{t('title')}</h1>
}

    🏝️ Client page/component (+498B): app/checkout/page.js

    "use client"
import useTranslation from 'next-translate/useTranslation'

export default function CheckoutPage() {
  const { t, lang } = useTranslation('checkout')

  return <h1>{t('title')}</h1>
}

    Regarding routing:

    Next.js 10 introduced i18n routing support, allowing pages to be rendered by navigating to /es/page-name, where the page pages/page-name.js was accessed using the useRouter hook to obtain the locale.

    However, since the pages have been moved from the pages dir to the app dir, this i18n routing no longer works correctly.

    At Next-translate, we have chosen not to re-implement this functionality, as we aim to be a library for translating pages, rather than routing them. We hope that in the future, this feature will be implemented in the app directory, as it is still in beta and many features still need to be supported.

    However, all the support currently available is with the lang parameter. That is, /es/page-name?lang=es renders the page app/page-name/page.js, where we have internal access to the lang parameter, and you do not need to do anything extra other than using the useTranslation hook to consume your translations.

    All the same, if you wish to use the language as a subpath /es/page-name without the param, you can utilize middleware to append the lang parameter and perform a rewrite:

    // middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import i18n from './i18n'

// /es/page-name -> rewrites to -> /es/page-name?lang=es
export function middleware(request: NextRequest) {
  const locale = request.nextUrl.locale || i18n.defaultLocale
  request.nextUrl.searchParams.set('lang', locale)
  request.nextUrl.href = request.nextUrl.href.replace(`/${locale}`, "")
  return NextResponse.rewrite(request.nextUrl)
}

    Here in the middleware, we are not adding the locale as a subpath, but rather eliminating the need to manually add the lang parameter. By default, the subpath still exists, but you cannot use useRouter from next/router to access the locale within the components of the app directory. Therefore, we still need the parameter, even if we hide it from view.

    And to navigate:

    <Link href={`/?lang=${locale}`} as={`/${locale}`}>{locale}</Link>

    If you need more i18n routing features like automatic locale detection you can follow these steps from the Next.js documentation:

    15. Demos

    Demo from Next.js

    There is a demo of next-translate on the Next.js repo:

    To use it:

    npx create-next-app --example with-next-translate with-next-translate-app
# or
yarn create next-app --example with-next-translate with-next-translate-app

    Basic demo

    This demo is in this repository:

    • git clone git@github.com:aralroca/next-translate.git
    • cd next-translate
    • yarn && yarn example:basic

    Complex demo

    Similar than the basic demo but with some extras: TypeScript, Webpack 5, MDX, with _app.js on top, pages located on src/pages folder, loading locales from src/translations with a different structure.

    This demo is in this repository:

    • git clone git@github.com:aralroca/next-translate.git
    • cd next-translate
    • yarn && yarn example:complex

    With app directory demo

    Similar than the complex demo but with some extra: Instead of pages folder, we are using the Next.js +13 app folder with the new layouts system.

    This demo is in this repository:

    • git clone git@github.com:aralroca/next-translate.git
    • cd next-translate
    • yarn && yarn example:with-app-directory

    Without the webpack loader demo

    Similar than the basic example but loading the page namespaces manually deactivating the webpack loader in the i18n.json config file.

    We do not recommend that it be used in this way. However we give the opportunity for anyone to do so if they are not comfortable with our webpack loader.

    This demo is in this repository:

    • git clone git@github.com:aralroca/next-translate.git
    • cd next-translate
    • yarn && yarn example:without-loader

    Contributors ✨

    Thanks goes to these wonderful people (emoji key):

    Aral Roca Gomez
    Aral Roca Gomez
    🚧 💻    		 Vincent Ducorps
    Vincent Ducorps
    💻    		 Björn Rave
    Björn Rave
    💻    		 Justin
    Justin
    💻    		 Pol
    Pol
    🚇    		 Ademílson F. Tonato
    Ademílson F. Tonato
    💻    		 Faul
    Faul
    💻
    bickmaev5
    bickmaev5
    💻    		 Pierre Grimaud
    Pierre Grimaud
    📖    		 Roman Minchyn
    Roman Minchyn
    📖 💻    		 Egor
    Egor
    💻    		 Darren
    Darren
    💻    		 Giovanni Giordano
    Giovanni Giordano
    💻    		 Eugene
    Eugene
    💻
    Andrew Chung
    Andrew Chung
    💻    		 Thanh Minh
    Thanh Minh
    💻    		 crouton
    crouton
    💻    		 Patrick
    Patrick
    📖    		 Vantroy
    Vantroy
    💻    		 Joey
    Joey
    💻    		 gurkerl83
    gurkerl83
    💻
    Teemu Perämäki
    Teemu Perämäki
    📖    		 Luis Serrano
    Luis Serrano
    📖    		 j-schumann
    j-schumann
    💻    		 Andre Hsu
    Andre Hsu
    💻    		 slevy85
    slevy85
    💻    		 Bernd Artmüller
    Bernd Artmüller
    💻    		 Rihards Ščeredins
    Rihards Ščeredins
    💻
    n4n5
    n4n5
    📖    		 Rubén Moya
    Rubén Moya
    💻    		 Tom Esterez
    Tom Esterez
    💻    		 Dan Needham
    Dan Needham
    💻 ⚠️ 📖    		 Bruno Antunes
    Bruno Antunes
    💻    		 Kaan Atakan
    Kaan Atakan
    💻    		 Romain
    Romain
    💻
    Arnau Jiménez
    Arnau Jiménez
    💻    		 Edwin Veldhuizen
    Edwin Veldhuizen
    💻    		 Duc Ngo Viet
    Duc Ngo Viet
    💻    		 Billel Helali
    Billel Helali
    💻    		 Wuif
    Wuif
    💻    		 Michał Bar
    Michał Bar
    💻    		 Wuif
    Wuif
    💻
    Marces Engel
    Marces Engel
    💻    		 Michał Bar
    Michał Bar
    💻    		 Dragate
    Dragate
    💻    		 Marces Engel
    Marces Engel
    💻    		 Vasco Silva
    Vasco Silva
    💻    		 Vsevolod Volkov
    Vsevolod Volkov
    💻    		 Felix Yan
    Felix Yan
    📖
    Muhammad Al Ziqri
    Muhammad Al Ziqri
    💻    		 Marcelo Oliveira
    Marcelo Oliveira
    💻    		 Zack Sunderland
    Zack Sunderland
    💻    		 Andrew Ovens
    Andrew Ovens
    💻

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

    Show All