i18n for Serverless Next.js app

[guykogel]

Hi guys,
We are about to start develope i18n support for our next.js app. I would love to know if translations for serverless apps is in the roadmap for the near future before we develope out custom solution?
Thanks

[kachkaev]

For now a common solution is https://github.com/isaachinman/next-i18next. It does not support serverless though and relies on your app having a custom express server.

UPD (2021-10): next-i18next supports serverless Next.js apps since v5 (you don’t have to create a custom server).

[mvanaltvorst]

@isaachinman @ferlopezm94 Are you sure next-i18next still supports next export? It seems like the docs suggest otherwise, together with my personal experience.

[hvdson]

@mvanaltvorst from what i've researched so far it seems like vercel doesn't plan on adding support for next export...i've been pulling my hair out the past week b/c of this #18318 (comment)

[isaachinman]

No, next-i18next does not support next export, and as far as I know, the Vercel team doesn't plan to continue supporting it in a first-class way. SSG achieves the same net result, with far superior flexibility.

[isaachinman]

@kachkaev Mind updating the comment to reflect the current state of things?

[kachkaev]

Good point @isaachinman! Done.

[guykogel]

@kachkaev thanks but I meant for serverless. I updated the title.

[isaachinman]

next-i18next now supports serverless apps via getStaticProps or getServerSideProps.

[janus-reith]

Still struggling to find a clean and simple solution for this.

I'm currently using next-i18next, but that requires a HOC with getInitialProps on _app.js which is not only incompatible with static rendering, but also is against the recommendation to only do this on a per page basis.

Then there is https://github.com/fwojciec/simple-i18n-example which uses dynamic routing and no custom server, but again requires a HOC that uses getInitialProps.

Another example is https://github.com/vinissimus/next-translate which allows for static rendering by using a separate folder pages_ which is used to then build the actual pages folder with subpaths - This seems like a workaround and I believe there could be a cleaner approach, maybe using getStaticProps. Also I didn't investigate how the default language is chosen here, but routing this should probably be simple.

Now that the nextjs team recommends static pages as a default, it would really be helpful to get their opinion, or even better, an example on how i18n should be implemented properly, as this really is a common requirement.

[isaachinman]

next-i18next now supports serverless apps via getStaticProps or getServerSideProps.

[janus-reith]

It might be worth it to use https://github.com/fwojciec/simple-i18n-example as a base, but simply remove the browser language detection in getIntialProps.

I made a quick example for this: https://codesandbox.io/s/serverless-i18n-s0t6h
(Certainly, credit mostly goes to @fwojciec for the original one, I only quickly adjusted the HOC).

For demonstration purpouses this now simply defaults to "en" at first, and there are several options to deal with this, for example:

1. Use a custom server to redirect to the correct page based on the browser language,
   Maybe nextjs api routes would also work, I did not try them yet but assume the issue with them is, that they need a separate /api folder and therefore can't be used as index page.
2. Simply redirect during runtime with useEffect/componentDidMount. The disadvantage here would be, that the non-default language viewers have a minimal longer loading time due to the redirect. This is currently done in index.js

One minor restriction of this approach is, that the language path is not freely configurable but sits on the beginning like: domain.com/language/page1 domain.com/language/page2, as else you would need to replicate this structure for each path.

Also, I don't know yet how well this will scale if you have several languages and everything is included per page.
Still, for simple usecases this will probably offer a way better performance than relying on a dynamic sever render each time.

[Janpot]

I'm working on an alternative which takes the approach of building a Next.js application per locale, and relies on webpack aliasing features to distribute the localized strings to each app. I made an example which deploys to ZEIT now: https://github.com/Janpot/nymus/tree/master/examples/next.js.

The key elements are:

1. a folder per locale containing json files with localized messages
2. a configurable next.config.json, with an alias to the current locale
3. The nymus compiler, which turns strings into react components (this is kind of optional, but it will take care of tree-shaking unused messages)
4. a basepath, and a rewrite for each locale (experimental Next.js features)
5. a deploy script that creates a deployment for each locale in the same ZEIT project, then collects all the deployment urls, and creates a final deployment with the rewrites.

Disclaimer: I don't have it anywhere in production yet. This approach and code should only serve as inspiration. The nymus package is a working but not widely used library, and the example is relying on Next.js experimental features.

[janus-reith]

@Janpot Interesting, thank you for sharing this. I'm wondering, what was the main blocker or reason that made it more feasible for you to actually build separate applications per locale despite the added complexity?

[Janpot]

@janus-reith For me, the main unresolved question/problem here is:

Given a set of messages, how am I going to make sure that only the messages that I use on a certain page are shipped with the resources of that page?

One approach could be to separate these out in one namespace per page and to make sure you only ship that namespace when you transfer messages. This should be relatively straightforward to build right now I guess with getStaticProps/GetServerProps.

Another approach could be to make sure that messages are just normal ES6 modules with named exports and use them like any other code, then have the build system tree-shake away whatever is not used. And if you generate highly optimized components like nymus does, the runtime overhead is also lower than the previous approach.
This is the approach I'd like to explore because it requires no extra manual ceremony and housekeeping as messages are added/removed. It also just relies on already existing and battle tested tooling. In my opinion this doesn't add complexity, it takes complexity away. And it does it while producing smaller bundles and more performant code. It should also just work with any approach you want to take that Next.js supports: SSR, SSG

what was the main blocker or reason that made it more feasible for you to actually build separate applications per locale

The fact that for this approach you'd need to be able alias a module per locale. Which in practice means, a different alias per basepath. I don't think there is any other way to do it currently with Next.js. It's easy to add custom webpack configuration for the whole application, but not if you want to do it more fine-grained. And if run as serverless, it should have no overhead at all whether it's 1 or 10 applications.

[janus-reith]

I created a new example, which uses static props to generate locale subpaths during build, supports namespaces and only bundles necessary strings for each page:

https://codesandbox.io/s/nextjs-i18n-staticprops-92ebn

Instead of API routes I just import them in the staticProps step and treeshaking works fine here so only the necessary ones are included.
For now I'm quite happy with this solution.

One thing missing is to add rewrites using the pattern described in #9081, so a path like "/de/someSubdir/test" would also work without a defined locale as "/someSubdir/test".
I currently have a catch for this in place in the toplevel index.js so something like /about would be routet to /[lang]/about, but this would currrently fail at the second level, as for "/someSubdir/test" it would be required to have another folder called someSubdir on the same level as the [lang] folder, and with more nested paths this would easily get confusing and too verbose, so I'll try to come up with something better here.

Some note for testing Static Props seems to behave different during development than I expected. When I first tried to disable browser scripts to see the initial rendering I got a blank page and thought things didn't work out. But running a production build (npm run build && npm start) produced static files which include the correct strings and works as expected.

[Janpot]

👍 So that would basically be the first approach I mentioned in my previous comment. So some of the drawbacks I tried to solve with the other approach I describe are:

• It requires a lot of manual ceremony, like adding getStaticProps on every page, splitting strings into namespaces, and keeping them lean as your codebase changes over the years.
• You need to provide a context to distribute your messages into deeply nested components.
• It doesn't (yet) do advanced i18n features like inerpollation, pluralization, date formatting...

All these are fine tradeoffs of course, and your solution is good IMO. I just don't really think this is less complex.

[janus-reith]

@Janpot Right, let me rephrase that, what I had in mind was complex as in, is it possible to package it into one simple repo for beginners to check out and get started with, without the need for any existing infrastructure in place, just like most of the other nextjs example projects.

[Janpot]

is it possible to package it into one simple repo for beginners to check out and get started with, without the need for any existing infrastructure in place, just like most of the other nextjs example projects.

The folder I shared is independent of the rest of that repo. It works on its own, just like an example from the Next.js examples folder would.

[janus-reith]

Oh ok, sorry if I made false assumptions about your approach, will try it out.

[BjoernRave]

I am currently using https://github.com/vinissimus/next-translate . It adds a build step, but beside that everything works fine and on serverless

[janus-reith]

BTW in the meantime I revised my approach to also optionally be able work with getInitialProps as I have some dynamic and some static pages. Furthermore I now have proper Server Side Language detection in place, without needing getInitalProps or a custom server by using an API route which detects the language header of the request. Next I use the new experimental rewrites, so all routes without a language in their path are redirected to the api endpoint, which detects the language, gets all the remaining path segments in the query and redirects it to the localized route.

No unnecessary clientside redirect, no added build step and full static page support.
Feel free to let me know if there is a demand for that solution and I will try to put a new example together.

[janus-reith]

Regarding the query parameters:
Im not sure where the ?lang=terms you have comes from, I would need to check if that is actually related to my example somehow. The general reasoning behing this was that I had to deal with additional query parameteters coming from external sources for campaign tracking purposes, where I couldn't savely expect everyone to create urls in a compatible manner.
E.g. both https://www.example.com/?utm_source=something and https://www.example.com?utm_source=something should return working localized urls without stripping additional parameters.

[Vadorequest]

Thanks for the explanation, I had missing the trailing slash indeed, I get it now.

I changed it to the following, to handle any depth link (see UnlyEd/next-right-now@799c72a):

redirects() {
      return [
        {
          // Redirect link with trailing slash to non-trailing slash (any depth), avoids 404 - See https://github.com/zeit/next.js/discussions/10651#discussioncomment-8270
          source: '/:path*/',
          destination: '/:path*',
          permanent: process.env.APP_STAGE === 'production', // Do not use permanent redirect locally to avoid browser caching when working on it
        },
      ];
    },

With your version, going to https://ouyrb.sse.codesandbox.io/en/someSubdir/test/ will yield a 404, with mine, it'll work: https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-awe87sbix.now.sh/fr/terms/

---

Your reasoning behind query parameters forwarding is good, it's a necessity and will be necessary for any non-trivial app. It may be related to my own implementation and not yours. I can't reproduce the behaviour on your sandbox. It's weird that it behaves differently locally and online.

When you go to https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-awe87sbix.now.sh/terms, does it change to https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-awe87sbix.now.sh/fr/terms?lang=terms for you too? I wonder if it's not a "browser cache" related issue.

[Vadorequest]

@janus-reith FYI your regex matches any "string that begins with" instead of matching for the exact word. See UnlyEd/next-right-now#42 (comment)

enduro should be redirected to en/enduro, but right now it not caught by the rewrite rule

[janus-reith]

@Vadorequest Yes I'm aware of that and I'm already searching for a solution as seen in the linked path-to-regexp issue mentioned inside the one you linked ( which I opened there)

[Vadorequest]

@janus-reith Also, another thing to take into consideration:
UnlyEd/next-right-now#42 (review)

Basically, if an asset in /public is not found, it'll hit the rewrites rule and redirect to a page, which is likely not to exist, which will return a 404 page, and make everything harder to debug.

The fix would be to ignore the public folder in rewrites rules. I'll take a look at how to do that, but I hate regexes-ish.

---

Edit: Fixed by UnlyEd/next-right-now@fad1e2d

[Vadorequest]

We've built a Next.js boilerplate with built-in i18n at https://github.com/UnlyEd/next-right-now, it uses i18next and react-i18next, also, it uses Locize provider for fetching translations, but that can be changed.

In any way, it's a working implementation used in production that can also be used as a learning resource!

[janus-reith]

@Vadorequest Your boilerplate is using getInitialProps on _app.js and therefore wouldn't work for static pages.

[Vadorequest]

@janus-reith It's just a matter of implementation. We built it when SSG with Next wasn't even a thing, so we used a SSR approach with universal language detection.

It could be changed to client-side language detection fairly easily, and remove usage of getInitialProps on _app to leverage SSG, that's something I intend to try out soon enough.

---

Edit: I get what you mean, now that I'm a bit more acquitted with SSG. Working on UnlyEd/next-right-now#42

[fwojciec]

With Next.js 9.3 you can use getStaticProps/getStaticPaths to easily generate localized versions of pages -- no external packages needed.

Use dynamic routes to include the language code as part of the url (i.e. something like /pages/[lang]/index.ts) and then:

import React from "react";
import { NextPage, GetStaticProps } from "next";
import Home from "../../components/Home";
import { LanguageProvider } from "../../context/LanguageContext";

interface Props {
  locale: Locale;
}

const HomePage: NextPage<Props> = ({ locale }) => {
  return (
    <LanguageProvider lang={locale}>
        <Home />
    </LanguageProvider>
  );
};

export const getStaticProps: GetStaticProps = async ctx => {
  return {
    props: {
      locale: ctx.params?.lang || "en"
    }
  };
};

export async function getStaticPaths() {
  return {
    paths: [{ params: { lang: "en" } }, { params: { lang: "pl" } }],
    fallback: false
  };
}

export default HomePage;

For example implementation of LanguageProvider, etc. see https://github.com/fwojciec/simple-i18n-example - or just write your own.

If you need a more sophisticated approach with all the bells and whistles of a full-size localization library something like react-i18next is likely going to work better for you in the long run.

[janus-reith]

@fwojciec This is what I did in the codesandbox demo I posted earlier. I took inspiration from your approach and made a static variant of it.

[fwojciec]

Sorry, forgot about your post earlier -- it's a good example.

[moaaz-bhnas]

const HomePage: NextPage<Props> = ({ locale }) => {
  return (
    <LanguageProvider lang={locale}>
        <Home />
    </LanguageProvider>
  );
};

Would it still work and be generated statically if I had the <LanguageProvider> outside (in _app.js), and reset its value inside HomePage component?
Something like this:

const HomePage: NextPage<Props> = ({ locale }) => {
  const { setLanguage } = useContext(LanguageContext);
  setLanguage(locale);

  return (
      <Home />
  );
};

[Vadorequest]

@moaaz-bhnas Yes it would work fine. That's similar to how we do it with NRN https://github.com/UnlyEd/next-right-now

[moaaz-bhnas]

Ok. Thank you

[RWOverdijk]

What's wrong with just having a [locale] directory and getting the locale from router.query? I'm new with this whole next.js thing and I want to understand what the downsides of this approach are.

I see a lot of complex solution that make me wonder if I just have the wrong idea 😅

[Vadorequest]

@RWOverdijk That's basically what I did with UnlyEd/next-right-now#42

[nimabrownlee]

Is there any official solution?

[aralroca]

In my opinion, it would be good if there was an official alternative solution to
"dynamic routes" to handle at least the navigation, language and JSON locales of the pages.

This would facilitate the use of many i18n libraries (or if you even want to do it without libraries) by forcing it to work with Automatic Static Optimization.

Proposal

/locales

locales
├── de
│   ├── common.json
│   └── home.json
├── en
│   ├── common.json
│   └── home.json
├── es
│   ├── common.json
│   └── home.json
├── fr
│   ├── common.json
│   └── home.json
└── it
    ├── common.json
    └── home.json

next.config.js

export default {
 i18n: {
    languages: ['en', 'es', 'fr', 'it', 'de'],
    defaultLanguage: 'en'
 }
}

/pages/index.js

import useI18n from 'next/i18n'

export default function Home() {
  const { language, locales } = useI18n()
  const { common, home } = locales

  // ...
}

export function getStaticProps({ i18n }) {
  const { language, locales } = i18n

  // ...
}

export const config = {
  i18n: {
    locales: ['home']
  }
}

So you can render the page content using the language on front /en, /es instead of /... Taking care of dynamic routes... For example, for /pages/[slug].js the language is ignored in the slug: /en/some-slug.

And during the navigation using <Link /> or Router.push would be great to keep the current language on the front, unless you specify another one.

Then each i18n library could manage the locales with their API, extending the useI18n hook to do the translations.

[wilsonneto-swe]

I strongly agree with the point cited by the @aralroca, above ...

The only point I still miss about nextjs is a way to deal with multiple languages ​​in a simple way, as everything else is. If there was a way to use multiple built-in or facilitated languages ​​it would be wonderful. I didn't want to have a "build step", or a serverless function, or a custom server for this.

Having locales and hooking i18n or nextTranslate useTranslation would be awesome.
Thanks for all!

[Vadorequest]

@wilsonneto-dev If you want to use i18n with SSR (as your comment makes me suppose to), check out this implementation:

• https://github.com/UnlyEd/next-right-now/blob/v2-mst-aptd-gcms-lcz-sty/src/pages/%5Blocale%5D/examples/native-features/example-with-ssr.tsx#L46-L91
• https://github.com/UnlyEd/next-right-now/blob/v2-mst-aptd-gcms-lcz-sty/src/utils/nextjs/SSR.ts#L82-L84

Doesn't rely on a custom server, no build step for this page (SSR, on-demand per request). I use a rewrite rule but that's not required (which detects the browser locale and redirects to e.g: /en), you could also detect the locale right from the getServerSideProps.

[wilsonneto-swe]

@Vadorequest I'm cheking the links, thanks so much!!

[waptik]

@Timer mentioned #13511 in #13514 (comment). So I guess it 'should' be an official example. Not sure, so don't take my word for it.

fwiw it's not an official solution. It was community contributed and is a community library.

That's what i thought, which is why i mentioned "Not sure, so don't take my word for it". It's great to hear that you have plans for built in i18n

[DevAtHeart]

Okay so I have been looking into this from a pure SSR perspective (no SSG possible in my app anyways). I wanted to solve this without routes. My solution is not the best and I don't like it. It is not very performant I believe. But it works (for now, until nextjs supports it out of the box or someone finds a better solution) and it doesn't take a lot of code .

Needed dependencies:

• i18next
• i18next-browser-languagedetector
• react-i18next
• @unly/universal-language-detector

Note the lack of next-i18next and next-translate. We don't need that. No custom server.js or build step.

i18n.js

import i18n from 'i18next'
import LanguageDetector from 'i18next-browser-languagedetector'
import { initReactI18next } from 'react-i18next'

const options = (lng = undefined) => ({
  lng,
  resources: {
    en: { ...enNamespaces },
    de: { ...deNamespaces }
  },
// ...
})

let i18next
if (process.browser) {
  i18next = i18n.use(LanguageDetector).use(initReactI18next).init(options())
} else {
  i18next = (lng) => i18n.use(initReactI18next).init(options(lng)).catch(console.error)
}
export default i18next

Note the following:

• I use different exports on client vs browser.
  • The clientside uses LanguageDetector to determine the language and starts i18n immediately.
  • The serverside uses @unly/universal-language-detector package and passes the result in.
  • Yes, there might be some instances when this will produce different results on client and server (for instance when the user changes locale in browser settings). This will result in one language being SSRed and then it will visibly jump and display a different one on the client. You could turn of caching in LanguageDetector for that though.
• You have to include the resources as javascript objects into the i18n config.

_app.js

import { universalLanguageDetect } from '@unly/universal-language-detector'
import i18next from './i18n'

const determineLanguage = (req) =>
  universalLanguageDetect({
    supportedLanguages: SUPPORTED_LANGUAGES,
    fallbackLanguage: FALLBACK_LANGUAGE,
    acceptLanguageHeader: req.headers['accept-language'],
    errorHandler: console.error
  })

MyApp.getInitialProps = async (props) => {
  const language = determineLanguage(props.ctx.req)

  await i18next(language)

  return NextApp.getInitialProps(props)
}

Note the following:

• We have to wait for i18n to complete startup before we can start rendering any page. It will do that on EVERY navigation.

You can use namespaces, hoc, hook (basically all react-i18next features) with this approach.

Again, this can be a band-aid until something better comes along.

[Vadorequest]

Disclaimer: I'm the author of '@unly/universal-language-detector'.

You could optimise your client side bundle, and have only one source of truth by using '@unly/universal-language-detector' only, and removing 'i18next-browser-languagedetector'.

That's what I did with my i18nLocize implementation at https://github.com/UnlyEd/next-right-now/blob/v1-ssr-mst-aptd-gcms-lcz-sty/src/utils/i18nextLocize.ts#L327

Basically, I used '@unly/universal-language-detector' beforehand to provide the result to i18next, and make sure the detected language is the same across the app.

See _app where I perform the detection, which is similar to what you do (SSR only).
https://github.com/UnlyEd/next-right-now/blob/v1-ssr-mst-aptd-gcms-lcz-sty/src/pages/_app.tsx#L96

[DevAtHeart]

Thank you, your project surely was an inspiration for my minimal example!

[oceandrama]

@DevAtHeart Do you have some repo with this approach?

[jokester]

I had a tiny i18next binding library at https://github.com/jokester/i18next-react . It works with next.js without needing a custom server (but no effortless SSG).

It has a nextjs example at examples/nextjs-serverless. In SSR part, the example used accept-language-parser to pick language. The example is deployed at https://i18next-react.now.sh/ .

The code is actually quite simple, one may be able to do the same with react-i18next and its I18nextProvider (didn't try && didn't know this when I wrote this library).

Anyway hope it can be of some use for other people.

[aralroca]

I just wrote a proposal to simplify i18n. Feedbacks are welcome!

#14246

[michelalbers]

I used lingui js in my next application and made a redirect to the default language if no language is
present in the URL.

First you need to install lingui js and configure it.

Install dependencies

yarn add --dev @lingui/cli@next @lingui/loader@next @lingui/macro@next @babel/core babel-core@bridge
yarn add @lingui/react@next

Add lingui commands to package.json

{
  "scripts": {
    "start": "lingui compile && next start",
    "build": "lingui compile && next build",
    "extract": "lingui extract --clean",
    "compile": "lingui compile"
  }
}

Setup lingui via rc file

{
   "locales": ["de", "en"],
   "sourceLocale": "de",
   "format": "po",
   "catalogs": [
      {
         "path": "src/locales/{locale}/messages",
         "include": [
            "<rootDir>/src",
         ],
         "exclude": [
            "*/node_modules/*",
            "*/.next/*"
         ]
      }
   ]
}

Setup lingui in _app.tsx

_app.tsx

import { de, en } from "make-plural/plurals";
import { I18nProvider } from "@lingui/react";
import { setupI18n } from "@lingui/core";

export default function MyApp(
  props: { lang: string; catalog: any } & AppProps
) {
  const { Component, lang, pageProps, catalog } = props;

  const i18n = React.useMemo(() => {
    const i = setupI18n({
      locale: lang,
      localeData: {
        de: { plurals: de },
        en: { plurals: en },
      },
      messages: {
        [lang]: props.catalog.messages,
      },
    });

    i.activate(lang);

    return i;
  }, [catalog]);
  
return (
      <I18nProvider i18n={i18n}>
          <Component {...pageProps} />
      </I18nProvider>
  );
}

MyApp.getInitialProps = async (rootCtx) => {
  let { lang = "de" } = rootCtx.ctx.query;
  if (!lang.match(/^(de|en)$/i)) lang = "de";
  // @ts-ignore
  const catalog = await import(`@lingui/loader!../locales/${lang}/messages.po`);
  const appProps = await App.getInitialProps(rootCtx);
  return {
    ...appProps,
    catalog,
    lang,
  };
};

Redirect to default language if no language given:

pages/index.tsx

import { useEffect } from "react";
import Router from "next/router";

const defaultLanguage = "de"; // TODO: Maybe do browser detection

export default function Index() {
  useEffect(() => {
    Router.replace(`/${defaultLanguage}`);
  }, []);

  return null;
}

Leverage next.js dynamic routing

Add all pages under the [lang]/ directory using next.js dynamic routing (https://nextjs.org/docs/routing/dynamic-routes) and you are done:

.
├── [lang]
│   ├── page-a.tsx
│   ├── page-b.tsx
│   └── index.tsx
├── _app.tsx
├── _document.tsx
└── index.tsx

All lingui functions including macros work out of the box. I used lingui v3 here so I can leverage hooks.

There are no custom routes or server needed and deployment on vercel works as well. Only the active language is imported when using ssr to reduce the bundle size. Hope that helps someone!

[gelito]

Hi @michelalbers, can you show a fully functional example?? Because I have some doubts based on your example but looks awesome! Thx!!

[michelalbers]

Will do! Just give me some time :)

[isaachinman]

Hi all, just wanted to mention that we have successfully leveraged rewrites in next-i18next@beta to deploy a serverless i18next solution that includes locale subpaths, on Vercel: https://github.com/isaachinman/next-i18next/issues/274#issuecomment-655466925.

You can find the source code here.

[carlreid]

@isaachinman Does the beta work with SSR/SSG?

[isaachinman]

@carlreid It's SSR, yeah, as we still have a dependency on a server(less) runtime to do things like evaluate cookies and potentially 301, etc.

[pimvh]

Hi @isaachinman, Thanks for providing a solution. I've been struggling with an implementation of localization in Next.js myself. Due a lot of options being available, I want to stay as close to the original repo as possible.

I've tried running your example (with npm run dev), but am getting some errors:

SyntaxError: Unexpected token { at createScript (vm.js:80:10) at Object.runInThisContext (vm.js:139:10) at Module._compile (module.js:616:28) at Object.Module._extensions..js (module.js:663:10) at Module.load (module.js:565:32) at tryModuleLoad (module.js:505:12) at Function.Module._load (module.js:497:3) at Module.require (module.js:596:17) at require (internal/module.js:11:18) at Object.<anonymous> (...../next-i18next-vercel/node_modules/next/dist/build/webpack-config.js:1:540)

I guess this is a dependency issue, but I can't seem to solve it. Could you have a quick look at it?

*edit for styling mistakes

[isaachinman]

@pimvh If you believe you've found a genuine bug, please open an issue in the next-i18next repo.

[cseas]

I just added a serverless example with react-i18next. The code is available for review at #14978

The only dependencies needed apart from the default Next.js setup are i18next and react-i18next. This example doesn't use any extra server setup or dependencies hence should be able to retain all features offered by Next.js.

[Progressandro]

Hi @cseas ! Is there any example that also includes logic for locale-based subpaths feature?

[cseas]

@Progressandro I made this example because I didn't want to use locale-based subpaths. But I think the rosetta based i18n example uses subpaths so that might be a useful reference.

[wiesson]

Did anyone come up with a slim solution that does not require external plugins for this topic?

I'd like to use:

• file based routing (e.g. /[:lang]/.../) ✅
• getStaticProps / Incremental Static Regeneration to refetch language keys if required ✅ (not required though, just nice to have)

My concerns are:

• "prop-drilling" for language keys, I don't want to pass the required texts to the outer component "leaves", so a context hook might work, but I need to test if it works with SSR ❓
• Tree shaking of unused language keys (I have like 1200 language items as (key/value), e.g. DASHBOARD_TITLE or DASHBOARD_COOLFEATURE_BUTTON_SAVE) and I don't want to add 1200 key/value items to each page, if they are not in use ❓

[StarpTech]

This could even be the starting point of a new i18n library for Next.js!

I already thought about it 😸

[StarpTech]

I released it under https://github.com/StarpTech/next-localization

[wiesson]

I released it under https://github.com/StarpTech/next-localization

Looks nice and clean, I will have a detailed look. From dashboard.js

import DE from '../locales/de.json';
import EN from '../locales/en.json';

I think this could be improved, or is webpack/next somehow able to detect unused imports and drop them?

[StarpTech]

Thanks, this is just an example. You can lazy load the language on the client-side or in server hooks at build time.

[ReangeloJ]

@StarpTech thanks for the amazing library! Do you happen to have an example of multiple namespaces? I didnt really get how to do that with different providers. Should I create an [name].json file for every provider. So provider for page1.json and page2.json for example.

[leerob]

Check out the new i18n RFC and give us your feedback! 🚀

[lfades]

Next.js Internationalized Routing (i18n) has been released in Next.js 10 one month ago. Check out the Next.js 10 blog post and the official i18n documentation to learn more.

[Lunnatica]

Hi! Did you manage to make it work only using the i18n capability of next.js? I've tried it and it works well for every locale except for the default one. It returns 404 for all the subpages unless I add the default locale suffix (which would mess with the SEO of the page). Any help would be appreciated!

[mvanaltvorst]

Hi @lfades, what would you recommend for internationalisation for statically generated websites?

[lfades]

@mvanaltvorst Next.js i18n works for that case.

[PrimozRome]

We are transferring our website https://dewesoft.com to Next.js where we have the same need of setting up translated static and dynamic routes. It's important for the SEO to have translated URLs. And of course we would like to keep the existing URL structure!

Static routes

/about
/es/nosotros
/de/uner-uns

/contact
/es/contacto
/de/kontakt

Dynanic routes

/[locale]/[product-page-slug][category-slug][product-slug] 

this can translate into:

• EN -> /products/systems/product-one
• ES -> /es/productos/sistemas/producto-uno
• DE -> /de/produkte/systeme/produkt-eins

Is this possible to setup?

[isaachinman]

You can add a redirect, or a 404. All this information is available in the docs.

[PrimozRome]

@isaachinman sure I understand that and was reading that as well. But is this how Next.js will handle URL translation situations? That basically mean with dynamic blog or product routes you need to maintain hundreds of rewrites and redirects.

[Vadorequest]

There is a general lack of guidance regarding this particular feature. I've been using Next.js for several years and this question regularly pops. Indeed, the docs don't explicitly cover this use case, and it's usually up to the author to find a "creative" solution.

Next.js doesn't cover i18n greatly, there is very basic support and it's also fairly recent. (about a year?)

I wouldn't know exactly how to build such feature if I had to implement it today. Dealing with static paths looks like a lot of manual config (path by path), and dealing with dynamic urls seems even more complicated.

[mehmetpekcan]

@PrimozRome Yes, you are right for those generated URLs you should write another rewrites config too. Like:

async rewrites() {
    return [
      {
        source: '/nosotros',
        destination: '/about'
      },
      {
        source: '/es/about',
        destination: '/nosotros'
      }
    ]
  }

It looks a little bit dirty but if you separate your language files, it will be good

[PrimozRome]

@mehmetpekcan I don't want to go rewrites way. Manging 9 languages with static/dynamic routes and rewrites seems something very sensible to human errors and painful to maintain... It is just not a good solution for larger sides. I see it working for a site with couple of routes, but if you have many of them and 9 languages it won't work on a long run.

I found this package https://github.com/hozana/next-translate-routes which seems to solve this problem, but I need to test it. I will get back with comments when I have more information on it.

[jferrettiboke]

My preferred way to translate pages (marketing site context) while having different localized slugs is to use a CMS (I recommend Sanity.io) and Next.js with optional catch all routes + getStaticPaths + getStaticProps.

This approach will allow you to change content faster, and have everything translated including slugs while delivering a great user experience to your users since all pages will be built upfront of users' requests.

[PrimozRome]

@jferrettiboke can you tell more about this implementation or would you be willing do discuss this privately? We do use content CMS (DatoCMS) where we define slugs per language. Thank you.

[jferrettiboke]

@PrimozRome I have created an i18n dynamic routing example, and sent a PR to Next.js just in case others are interested to see how it works.

Let me know whatever!

[isaachinman]

This CMS-slug-driven pattern is also one I have implemented across several large orgs. Simply fetch all pages by locale inside getStaticPaths, and fetch the data itself inside the subsequent getStaticProps.

It should be noted that if you have hundreds or thousands of pages, a cache layer will help immensely with build times.

[nbouvrette]

We just released a solution that supports serverless (and localized) URLs out of the box - looking for more community feedback! https://github.com/Avansai/next-multilingual

[nbouvrette]

Yep, I understand that. Side stepping SSG purely for locale detection is an antipattern, in my opinion. Pages should be SSG wherever possible, and locale detection should happen via a separate lambda.

@isaachinman not sure why you think it's an anti-pattern? if you want to do dynamic locale detection and SSR, you need to do this and this is the only way you can use the x-default alternative link which I believe is a better option than doing a redirect for example.

That said, some features you've got here, like canonical link generation, look cool! Will keep an eye on the project 👍

I think one of our core features is the localized URLs but also the modular string management which I haven't found in any React-based library before.

Watching this closely. URL translation is one of the key concepts we use with our multilingual websites. We are moving site to NextJS and so far we wanted to solve URL translation by using Catch all routes.

@PrimozRome it took us +8 months to get what we believe is the best solution (so far) to localized routes. If you use configuration to do this, the challenge will be when you do the translation. This is why our solution has the same files for both strings and routes which is localization-friendly.

It would be quite good if you could provide examples with dynamic routes. For example when you have blog-blog_category-post type of side or products-product_category-product and you need to have individual slugs translated...

We haven't tested dynamic routes yet, but it is one of the features we want to support (and document) in the near future. I am not sure if I understand the example you provided but please open an issue if you would like us to look at a specific example. Normally if your localized URL segment is from a blog, the blog should be responsible for the localization process.

[isaachinman]

not sure why you think it's an anti-pattern?

Because you are delaying the rendering of a page, which presumably could be done at build time, just to be able to negotiate an accept lang header. This is not using the NextJs framework in the way it is intended to be used.

[nbouvrette]

I wouldn't call using getServerSideProps an anti-pattern, especially if you consider that the native Next.js implementation uses an HTTP redirect, which means 2 HTTP calls. Also based on Lighthouse reports, the performance is our homepage is 100%, go check it yourself!

[isaachinman]

Using SSR only to perform header negotiation is an antipattern, unless you need to render different content on the same route.

Latency added from SSR is entirely unknown and will vary wildly based on any given project.

Latency added from a standalone lambda checking headers is stable and will not change if your source code changes.

[nbouvrette]

Using SSR only to perform header negotiation is an antipattern, unless you need to render different content on the same route.

Well, this is exactly what is going on here. Content will be served in the language most suited for the user, without using a redirect.

Latency added from SSR is entirely unknown and will vary wildly based on any given project.

I am coming from a PHP background nothing is statically generated and nobody worries about this - in fact, performance can match Next.js' if you know what you are doing. I literally just ran 2 Lighthouse tests and the First Contentful paint was 0.9s on a static page and 0.5 on the homepage 🤷

Also if you want to worry about SSR latency, you could do the same for the network, the shared infrastructure your app is being hosted on, etc.

Latency added from a standalone lambda checking headers is stable and will not change if your source code changes.

Not too sure I understand what you mean here - there are many ways to host Next.js to make it performant. On our end, our solution works out of the box on both Vercel and Netlify. Lighthouse scores seem pretty good, so I would definitely not call what we put in place an "anti-pattern" but if you have ideas on how to make our solution even better let us know :)