[Proposal] i18n for SSG + next export

[aralroca]

Feature request

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

Currently, integrating i18n libraries with Next.js and working with Automatic Page Optimization (either SSG, or totally static) is quite cumbersome.

It would be great to have something simple and portable, compatible with next export.

Using Dynamic routes requires a /[lang] folder to have each page as /en/example. You have to write a getStaticPaths and getStaticProps on each subpage to download the corresponding JSONs. Also, you need a language/locales context provider on the top of the page. And it gets even more complex with nested Dynamic routes and fallbacks. This alternative works in some projects but can be hellish in others.

Using rewrites looks like a good alternative to simplify Dynamic routes. However, you can't do next export, because next export does not have any special behavior for rewrites.

Describe the solution you'd like

I understand that Next.js may give you the freedom to choose which i18n library to use. With that in mind, I propose to keep using any i18n library, but forcing them to work with Automatic Page Optimization by default. And simplifying the process.

/locales folder

Just as /pages folder is useful to directly define pages, it would be great to have a folder /locales. Then you could define each supported language with their JSONs.

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

With this structure, we should know what languages are supported in the app without any extra configuration. The default language could be renamed with some extra special character, like Dynamic routes do. Example of defining en as default language:

locales
├── de
│   ├── common.json
│   └── about.json
├── _en_
│   ├── common.json
│   └── about.json
├── ...

Perhaps, it should allow some config on next.config.js for advanced things.

Usage in pages

import useI18n from 'next/i18n'

export default function About() {
  const { language, locales } = useI18n()
  const { common, about } = locales

  // ...
}

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

  // ...
}

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

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

You could render the page content using the language on front; /en instead of /, taking care of dynamic routes. For example, for /pages/[slug].js the language is ignored in the slug: /en/some-slug.

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.

Describe alternatives you've considered

I've considered next export to take account of rewrites. It would still not be a 100% friendly solution, but it would make it quite easy. I suppose there must be a reason behind it not being implemented.

Additional context

A little more than 6 months ago I published next-translate trying to make i18n + Next.js easier after seeing its complexity, although I think that the solution I implemented is a bit "hacky". It would be nice if Next.js managed this just like it does with pages.

I hope this will help us find a simple and efficient solution.

[revskill10]

In my case, all of my locales translation is from database, so i don't think an opinionated file system based locales folder is good enough to cover some "more than basic" use cases.

[Vadorequest]

Except if you're doing SSG only, because you could load your translations and generate your locales on the fly, at initial build time, but also during revalidation (if you use it).

But then, you might need a proper caching strategy.

[aralroca]

@revskill10 you are right. Maybe will be better to define the languages and default language in next.config.js level.

But with this, you will be able to use:

export async function getStaticProps({ i18n }) {
  const { language } = i18n
  const translations = await fetchTranslationsFromDB(language)

  // ...
}

with the following advantages:

• It works with nested dynamic routes, even if they have a fallback.
• Navigation with the current language will be handled internally.

[javiercr]

I'd love to see some sort of i18n support baked into next.js 🙌

Would this proposal support i18n of routes without an explicit locale prefix? eg:
en => /search
es => /buscar

IMHO this is key for SEO and so far the only way to achieve it with next.js is using custom servers, which takes away from you many of the benefits of next.js

[aralroca]

@javiercr I wrote a minimal configuration, but this can be extended to something like:

export const config = {
  i18n: {
    locales: ['about'],
    name: { es: 'acerca' }
  }
}

It would be a great idea if Next.js manage these i18n navigation internally with Router.push and Link. Not only for adding the lang on front. Otherwise it's quite cumbersome.

[jlopezxs]

We spend 3 month searching a good i18n option and didn't find a good one for next.js. All the options requires a feature sacrifice.

Your idea of use rewrite looks nice. I think you can unify all the routing system in a config file, simplifiying it. And less attached with the idea of a future next.js 18n official lib.

//next.config.js
{
    ...
    routes: {
        home: {
            paths: ['/en','/es']
            source: '/home/index.jsx', 
        },
        product: {
            paths: ['/en/products/:id','/es/productos/:id']
            source: '/product/[id].jsx', 
        }
    }
}

With this concept you can use a lib like https://github.com/lukeed/rosetta or plain json files and generate your translated paths before the next.js app starts.

[rafinskipg]

@jlopezxs What was your final solution? I need to implement i18n but i don't know what to choose.

[StarpTech]

Rosetta inspired me to create https://github.com/StarpTech/next-localization

[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.

[aralroca]

Sounds great @isaachinman ! The idea of this proposal is to support i18n for SSG and static pages. As I see, it still requires a getInitialProps on each page to download the correct namespaces depending on the language, isn't it?

Would be great if you give some feedback about the above proposal 😊

[isaachinman]

@aralroca That's correct, moving away form getInitialProps is the next goal. The tricky part about achieving SSG is how you manage cookies/sessions, and redirects therein.

[leerob]

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

[aralroca]

I will mark this discussion as resolved, in favor of the RFC.

[rokinsky]

@leerob the RFC doesn't contain next export option

[Yrobot]

Hi guys. I have just published a package for i18n next.js project SSG export, which called i18next-ssg.

With i18next-ssg, you could handle the i18n logic for next.js SSG easily.

Here is an example, if you have the pages defined like this:

After you run yarn build, the output files under the build folder will look like this:

/ will redirect to /[locale],/arya will redirect to /[locale]/arya, the locale value will be detected automaticaly.

This is the demo for this package: https://codesandbox.io/s/i18next-ssg-ozrpwx
This is the package github repo: https://github.com/Yrobot/i18next-ssg

[christophrathvaltech]

Does this lib also work with the new 'App Router' Paradigma ?
If yes could you add an example on how to use it?