i18n and routing

[simonpca]

Hey!

So stoked to get to use Next 10 a reallife client project, but I'm currently stumped w/ the new internationalization feature.

I need my routes slugs to be translatable, so instead of

/carrieres
/carrieres/:slug

/en/carrieres
/en/carrieres/:slug

I need to be able to have a different slug by language, e.g.

/carrieres
/carrieres/:slug

/en/careers
/en/careers/:slug

I'm (sadly) aware this was not included in the i18n RFC, but I really (badly) need those page names to be translatable.

I tried fooling around with rewrites, without any success (it broke + it wouldn't work w/ client-side routing)
I found nuxt-roots which felt promising (albeit a little bit sketchy), but didn't work at all, not even compiling.

I'm at a total loss with a client that insists on having localizing routing.
Any ideas on how I could work arount this current limitation?

Thanks!

[delucca]

I'm facing the same issue as you.

I've also posted a question here too, but no answers provided.

The solution I found was either of the following options:

1. Using a proxy at next.config.js to proxy multiple routes to the same addres, and the creating a withProxyRoute HOC for the proxied pages to redirect to a given route based on locale
2. Using next-translate to build my static pages automatically

The first option seems to be the most suitable and stable solution, but there are some caveats in it. I'm still thinking how to approach this issue.

[mimoid-prog]

Yeah, I need this feature too. I also posted about this but idk if someone saw that. I hope they will provide a config for translating routes soon.

[hk86]

I had a similar requirement and managed to achieve what I want. I have two locales de and en. en is the default locale. For en I do want /hello and for de /de/hallo. In order to achieve that I have a file /pages/hello in next.config.js I defined a rewrite:

      {
        source: "/de/hallo",
        destination: "/hello",
      }

I guess the initial release of nextjs 10 had a bug, therefor I upgraded to the latest canary version. Is that what you are after?

[mimoid-prog]

Yes, it is exactly what I need. But where do you put this object in next.config.js? Could you provide your whole configuration? And how did you know about that, is it somewhere in docs?

[ynnoj]

@mimoid-prog https://nextjs.org/docs/api-reference/next.config.js/rewrites#rewrites-with-i18n-support

[csantos1113]

I believe destination is going to affect the page URL, right?
so when the user hits: example.com/de/hallo nextjs will replace the url to example.com/hello.

The idea is to keep de/hallo in the URL as a valid route and underline make it point to pages/hello.jsx file

[hk86]

Here you go:

module.exports = {
  i18n: {
    locales: [
      'en', 'de',
    ],
    defaultLocale: 'en',
  },
  async redirects() {
    return [
      {
        source: '/en/:path*',
        destination: '/:path*',
        permanent: true,
      },
    ];
  },
  async rewrites() {
    return [
      {
        source: "/de/hallo",
        destination: "/hello",
      },
    ];
  },
};

I think I read it in the RFC for rewrite and redirect. I had this logic already in nextjs 9, but back then I had to implement my own logic to have this subpaths. With nextjs 10 it is easier and has less boilerplate. As I said before you might need the latest canary.

[SalahAdDin]

This is not so optimal if you have to fetch the slugs from a backend, for example, Strapi.

[delucca]

@hk86 that is a great solution!

But how do you handle linking? I've tried your suggested config, but when I link in the client side from a page to the root page it ignores my locale config.

There is a simple way to link every page to /hello, for example, and it uses /de/hallo as path?

The only option I can think right now is creating a custom hook that returns a list of mapped paths, and the pass it to the Link component based on current locale.

[hk86]

Unfortunately this is not handled by nextjs. I wrap next/link in a custom component were I handle the logic for the mapping.

[delucca]

Thanks for your reply.

That is exactly what I am doing, I've created a custom Link component which uses next/link but pasing the localized route.

[BramDecuypere]

Looks like this would be the next improvement of the localisation?

Because indeed it would make sense to have a different path per language.
EG simplified example:

/nl/blog/
/fr/blogue/

Because with the redirect solution above I guess you are not able to keep that route displayed in the browser? @delucca @hk86

What I've done for our main page is abuse the [blog] syntax. But that's far from optimal, because you can only do it for one page on the same hierarchy level.

[mimoid-prog]

Because with the redirect solution above I guess you are not able to keep that route displayed in the browser?

Why not? With the rewrites you can copy the content of the /fr/blog to the new route /fr/blogue/ and then with the custom Link component you just need to redirect to the correct page - /fr/blogue instead of /fr/blog

[BramDecuypere]

Ok let me check that real quick. If it works as expected, because for now my solution looks like I'm creating the pages manually and only exporting the language that is necessary inside that file

[BramDecuypere]

Because with the redirect solution above I guess you are not able to keep that route displayed in the browser?

Why not? With the rewrites you can copy the content of the /fr/blog to the new route /fr/blogue/ and then with the custom Link component you just need to redirect to the correct page - /fr/blogue instead of /fr/blog

Looks like this is working indeed. I'm just wondering how you deal on this with SEO level? You just name the page component as one of the URL's and then rewrite the other one to point to that same page component?

No duplicate content involved like that I guess..

[delucca]

To solve this I've added the rewrites (not redirects) at my next.config.js, as the following:

module.exports = {
  serverRuntimeConfig,
  publicRuntimeConfig,
  i18n,

  async rewrites() {
    return publicRuntimeConfig.intlRoutes.map((route) => omit(route, ['locale']))
  },
}

As you can see, I'm using a custom key at publicRuntimeConfigcalled intlRoutes, and I'm omiting the locale key of it. Here is a sample of that key:

const publicRuntimeConfig = {
  intlRoutes: [
    {
      destination: '/keyResults',
      source: '/resultados-chave',
      locale: 'pt-BR',
    },
    {
      destination: '/keyResults',
      source: '/key-results',
      locale: 'en-US',
    },
  ],
}

It is basically a route that I would add to rewrites, but with a new locale key. Now, I've coded a custom Link component that imports the publicRuntimeConfig and check for a given root link (not localized) which is the correct route for it's locale.

In my opinion this is a must-have feature for any localized application. There is no sense in providing a localized page without a localized route.

[SalahAdDin]

How can we handle it when we have to fetch the slugs from a server like Strapi?

[hk86]

I've detected a major issue with this approach. I do not have the issue locally, but when I deploy to the Now platform: #18902

[SalahAdDin]

It was closed.

[landsman]

We had to do this middleware: https://github.com/trisbee/next-i18n-routes-middleware for our sites and still looking forward for official way how to achive simillar results without custom SSR.

[SalahAdDin]

Any progress on this one?

[sawik-code]

Anyone make it work to change language for different slugs per language? Am i missing something?

[OlgitH]

I need this feature as well

[kimgiutae]

Related issues #31178 and #18485