Internationalized routing with translation of pages names

[mimoid-prog]

Right now it is only possible to have internationalized routes like this:

/about
/fr/about
/de/about

What I want to do is to translate pages name too:

/about
/fr/sur
/de/uber

Some configuration object in next.config.js like this would be really cool:

i18n: {
  pages: [
    {
      about: {
        fr: "sur",
        de: "uber",
      },
    },
  ];
}

[simonpca]

Yes to this!

This is a somewhat hard requirement for any business website in order to provide a minimally adequate user experience (at least being able to read and share URLs that are in your native language). Having url segments in the wrong language also has a considerable impact on SEO.

Your idea looks a bit like the way nuxt-i18n implements it, with each page component being responsible to declare the route segment for each language (https://i18n.nuxtjs.org/routing#in-component-options).

It also goes as far as providing a way to fetch/supply the translated version for any dynamic parameter route (https://i18n.nuxtjs.org/lang-switcher/#dynamic-route-parameters).

I'm currently trying to figure out a way to kinda temporairly patch it on a NextJS 10 site with rewrites or something with really little success, looking forward for properly internationalized routes to be possible or a manual way to solve it in the meantime.

[mimoid-prog]

Let me know if you find a solution for this

[cywtf]

@simonpca did you find a solution for this? We are currently researching the same thing

[rimiti]

same issue for us. :/ Nuxtjs seems a real nextjs challenger. hum..

[carlossalasamper]

After developing in Nuxt for a few years I have switched to Next to test the experience, but the truth is that it has functionality like this (i18n) that is incomplete for a framework that is characterized by SSR

[dzcpy]

After developing in Nuxt for a few years I have switched to Next to test the experience, but the truth is that it has functionality like this (i18n) that is incomplete for a framework that is characterized by SSR

Yes, but Nuxt also has some issues. Like its version 3. You may also try Redwood.js and Remix

[delucca]

+1 for this feature request

My company (for example) requires exactly this feature to move away from i18n alternatives to use only NextJS instead.

[ostenning]

+1 for this also;
In the mean time, we are looking at using https://github.com/vonschau/next-routes-with-locale

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

[marcoantoni0]

+1 for this feature request

[gu-stav]

I believe this is now possible by using rewrites with beforeFiles:

// next.config.js

module.exports = {
  async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/fr/about',
          destination: '/fr/sur',
          locale: false
        },

        {
          source: '/de/about',
          destination: '/de/uber',
          locale: false
        },
      ],
    }
  },
}

You can find different examples here: https://nextjs.org/docs/api-reference/next.config.js/rewrites

[joaogarin]

But this will not change the URL path, so you still would be on /fr/about right? Rewrites don't change the path url unlike redirects, but redirects only work server side (are not client side aware)

[bitworking]

The example seems to be wrong. Corrected:

{
  source: '/fr/sur',
  destination: '/fr/about',
  locale: false
},

So if you got to the url "/fr/sur" in the background it handles it with the "pages/about" next page. So like I see it, the rewrite feature could handle the international routes well, right?

[sylvain-guehria]

it works ! =)

I had the exact same problem, thank you guys =p

[kimgiutae]

In my case... this couses 404 in both source and destination...

[joaogarin]

Hm interesting, I guess this could work. question is then any link inside the app, will not be reflected (if you have links to /about and switch to fr these links will still point to /about), you need some wrapper around the Link tag?

[muserref-sefer]

I'm also using rewrites for solution on production. https://nextjs.org/docs/api-reference/next.config.js/rewrites

[muserref-sefer]

async rewrites() {
    return [
      {
        source: "/giris", // My end user see only this turkish url
        destination: "/login", // Actually my file name is login
      },
   ]
}

If you are using the slug pages you must write the custom server with node js.

@jnthnk

[kimgiutae]

Thanks @msefer for the example.

I was thinking that source was the original path and destination the translated/desired path.

In the code you provided you didn't specify the language in the rewrites. How next will know the desired lang to rewrite ?

Also, why the need of a custom server ?

[muserref-sefer]

Actually my website is only turkish language and i am using the useFileSystemPublicRoutes: false and i need to custom server. But if you are using the english language also you don't need the custom server.

If you are using the slug pages you can use like this:

reset-password/[resetId].js

{ source: "/sifre-sifirla/:resetId*", destination: "/reset-password/:resetId*", }

@jnthnk

[kimgiutae]

Hi. @msefer I make it works thx. But sadly the wrong URL is still accesible.

[muserref-sefer]

Can you share your config file? @jnthnk

[Mooskopf]

Any updates on this? I am currently trying to solve this issue for my client too and rewrites seems like a suboptimal solution.

[ostenning]

Any updates on this? I am currently trying to solve this issue for my client too and rewrites seems like a suboptimal solution.

I think that rewrites are probably the best solution at this stage, as its an officially supported by nextjs.

Currently I am using a fork of https://github.com/vonschau/next-routes-with-locale for my projects specific needs, but its far from ideal and I think I will migrate to use the rewrite solution in the near future.

[kimgiutae]

In my case... rewrites are just causing 404 errors

[PrimozRome]

+1 for this. Migrating our existing page to NextJS and this is a major blocking issue for us currently...

[kimgiutae]

Also... we rlly want to migrate one big multilingual website built in WP multisite, to next, but we can't make the url translation.

We tried to use simply the built-in folder routing system to make the translations. Something like this:

pages/index.tsx (home english)
pages/about.tsx (about us english)
pages/news/[slug].tsx (news blog english)
pages/es/index.tsx (home spanish)
pages/es/nosotros.tsx (about us spanish)
pages/es/noticias/[slug].tsx (news blog spanish)

But this ends to be pointless if we can't make a dynamic lang attribute on _document.tsx.

At least we could modify the header content-language using the new _middleware.ts file on next12.

Please devs give us some light in this problem. i18n without the possibility to translate urls seems not too useful.

[jomarl]

File based routing in a nutshell. We ended up with a custom server, rewrites, a wrapper around the router, a custom Link component and a routes.config hacked together to support localized urls, or in our case site specific urls as our application is served from multiple domains (in native language per domain). E.g. essentially a good old routes.config file where all pages are given a logical name and a url mapping per site/lang to the nextjs page.

route: productsPage
page: /products/[slug]
urls:
  example.it: /producto/:slug 
  example.dk: /produkt/:slug
  ..

example.it/producto/123 -> /products/123
example.dk/produkt/123 -> /products/123
..

<HackyLink route="productsPage" slug=123>
    Products
</HackyLink>

routeName  = useHackyRouter().currentRoute()
useHackyRouter().push("productsPage",  ..)
localizedUrl = useHackyRouter().createUrl("producsPage", ..)

Doing stuff like this in any other tech our team have worked on have never been a big issue.

One of our worst hacks ever.

Champagne to Nextjs team when (if not already possible, eg. rewrites) stuff like this can be handled more or less out of the box.

Ad notam: File based routing is great for many applications, but for more complex use cases/applications it's just pure evil and results in half your team going bald due to stress.

[fatih-koc]

Its such a shame for nextjs developers not to have a proper, a web standard which is critical for accesibility and search engine optimization, still not there: a broken, half baked, not properly documented an i18n routing is still being ignored for more than 3 YEARS!

I love react but nextjs devs really made me hate nextjs as much as i can be. Even slugs doesnt change when you change language. wtf??

Look at this and drew inspirations and learn what is necessary to claim your framework as "supporting i18n"
https://i18n.nuxtjs.org/guide/custom-paths#page-component
@leerob @timneutkens

we had to learn nuxtjs, we had spend our 9 month to rewrite our projects in vue & nuxt ( which we dislike) but your attitude and ignorance on fixing your framework made us hate nextjs more!.

[emillind]

This is of major importance for my team as well

Essentially the same content should be available on different languages on:

• /platser/[region]/[slug] - swedish (default) route
• /en/locations/[region]/[slug] - english route

Ideally we would have a folder structure like so: pages/platser/[region]/[slug].tsx that would resolve both the paths mentioned above.

Basically what i am looking for is a way of doing this without having to have a /pages/locations folder, thus not having to duplicate code. I have tried doing this with rewrites but i am not succeeding in doing it, probably because we have two levels of dynamic in the route.

[aurelien-gaillard]

You can check my post to understand the logic, and in rewrites, put this code:

{
          source: "/en/platser/:param*",
          destination: "/en/locations/:param*",
          locale: false,
},

Don't hesitate to check the rewrites documentation for more infos.

[Bjornjansfelt]

@emillind Did you manage to solve this? I'm looking for a solution to the exact same problem?

[aurelien-gaillard]

This is the way how to solve your problem:
I used this code in production, it works well. If needed dynamic routing, check the documentation of rewrites to adapt but the logic is the same.

module.exports = {
  i18n: {
    locales: ["en", "fr", "de"],
    defaultLocale: "en",
  },
  async rewrites() {
    return {
      beforeFiles: [
        {
          source: "/fr/sur",
          destination: "/fr/about",
          locale: false,
        },
        {
          source: "/de/uber",
          destination: "/de/about",
          locale: false,
        },
      ],
    }
  },
}

Create a file route.js

export const routes = {
 about : {
  en: '/about',
  fr: '/fr/sur',
  de: '/de/uber'
  }
}

Use the next/link in your code as below:

<Link href={`routes.about[locale]`}>
  <a>About</a>
</Link>

[kimgiutae]

This is not an optimal solution... the incorrect paths are still acessible.

In your case "/de/about" and "/fr/about" doesn't causes 404 error or redirect as should be.

Also. With this approach how can you handle dynamic page generation with getStaticPaths ?

[PrimozRome]

Yup, I agree. Not an ideal solution!

[rasco]

@jnthnk why not just combine it with redirects?
like just add this to the above:

async redirects() {
    return [
      {
        source: '/de/ueber-uns', 
        destination: '/de/about-us', 
        locale: false,
        permanent: true
      },
    ]
}

As for dynamic page generation with getStaticPaths:
getStaticPaths supports a locales parameter, explained here: https://nextjs.org/docs/advanced-features/i18n-routing#dynamic-routes-and-getstaticprops-pages

[ostenning]

Crazy that this feature hasn't really had much traction considering its one of the biggest downsides to next for me and my clients. Its hard to recommend next for internationally target projects.

Has anyone got client-side transitions working with the next.config.js rewrites api? I can get server-side transitions working but not client-side, and I seem to get bundling errors in dev (hot reload) mode, these errors don't happen in production mode.

Also I was wondering if anyone know if it were possible to use the new nextjs 12 middleware api to do this? Would it be better?

[williamli]

Please check out #18485 (comment). You should be able to add some extra logic on top of my suggestion to handle translation at the middleware level depending on your needs.

[williamli]

Right now it is only possible to have internationalized routes like this:

/about
/fr/about
/de/about

What I want to do is to translate pages name too:

/about
/fr/sur
/de/uber

Some configuration object in next.config.js like this would be really cool:

i18n: {
  pages: [
    {
      about: {
        fr: "sur",
        de: "uber",
      },
    },
  ];
}

For your use case, you can adopt this solution #18419 (reply in thread) and add your own slug correction / redirection logic to the _middleware. For example, when a user visits /about, we know that a redirection is required. From there, you decide which locale we should send the user to, and then in the cms, you do a look up for the right translated slug and redirect the visitor to the correct URL.

/about
look for slug: about, figure out which locale to redirect user to, redirect to /${locale}/${translated-slug}

/fr/sur
look for translated-slug: sur with locale fr

/de/uber
look for translated-slug: uber with locale de

[noblica]

The rewrite solution doesn't work for me.
It works locally (if I run next build and then next start), however if I deploy it to vercel, I just get a 404. Does anyone have a solution for this?

[williamli]

Can you try to do it inside the middleware?

#18419 (comment)

[noblica]

Hey, I ended up coming back to this, and implementing it through middleware as suggested. It works, however I think this solution is a bit hacky for just localizing URL's, and the issue of rewrites not working on a vercel deploy still remain.

For my use case, I wanted to do a rewrite because of a localized url.
The original URL was /referenzen/:slug/, but for the english version, it needed to be /en/references/:slug/. I ended up creating a references folder which only housed _middleware.js file with the following content:

import { NextResponse } from 'next/server'

const PUBLIC_FILE = /\.(.*)$/

export function middleware(req) {

  // Only rewrite files that don't have a file extension
  if (!PUBLIC_FILE.test(req.nextUrl.pathname)) {
    req.nextUrl.pathname = req.nextUrl.pathname.replace('/references/', '/referenzen/');
    return NextResponse.rewrite(req.nextUrl)
  }
}

After implementing that the rewrite worked both locally, and deployed on vercel.

[Lorezz]

done the same thing but it does not work on netlify

[fatih-koc]

I cant believe how hard its to have localized dynamic slugs in next 12 without whacky hacks or third party libraries. We wanted to migrate our django + react website to nextjs for better performance yet It is crazily absurd to apply various fixes/hacks for weeks to accomplish what established frameworks can do for decades!

We do not want to depend on some other third parties which have no stability in future and we can not rewrite each god damn page. There are nested routes which we depend on to deliver content and we do not want to lose any traffic to our website like any reasonable web developer which we spent years of building content.

Instead of announcing incomplete versions with flashy showcases, why do not you build a proper working localized routes instead of manually rewriting each page?? I mean guys we have 60k of content in 7 languages and we are about to dump our nextjs migration!

Will you announce a future road map to deliver a truly i18n capability or should we dump our nextjs migration? We do not want to use any i18next or next-translate-routes packages. If you claim that nextjs is full frontend framework for react, you have to deliver something working in multiple languages. We do not live in a only english speaking world and truly international webpages delivers content in multiple languages with urls for each one!

[dzcpy]

You may try Gatsby, Remix and Astro instead. But I'm not sure if these frameworks even work better

[fatih-koc]

You may try Gatsby, Remix and Astro instead. But I'm not sure if these frameworks even work better

Correct me if i am wrong but: Gatsby for static website, we have over 72.000 pages of content from db, Remix doesnt even have i18n at all, Astro too does not offer internationalized routing even on their docs page when language switched (try and check if slug is changing in url bar).

[EddyVinck]

Tim Neutkens provided an update on Twitter:

This will be solved by "app" given that the built-in i18n feature will go away in favor of new core APIs that allow full flexibility for the i18n case. There were a lot of different requests regarding i18n, many opposing each other as every company does i18n differently.

[fatih-koc]

Tim Neutkens provided an update on Twitter:

This will be solved by "app" given that the built-in i18n feature will go away in favor of new core APIs that allow full flexibility for the i18n case. There were a lot of different requests regarding i18n, many opposing each other as every company does i18n differently.

Thank you Eddy, for bringing this issue to lead developer of NextJs. A few weeks ago, I replied same complaint to Lee Robinson and he did not even bother to reply. https://twitter.com/birarakisarap/status/1601574916712960000

[wceolin]

@fatih-koc Your Twitter account is private, so people who don't follow you can't see your tweets or reply to them.

[fatih-koc]

Thanks for warning @wceolin I made my account public, now you can see my tweet about topic. sorry, I live in a country which i can be targeted by radicals therefore i made it private.

[leerob]

Sorry @fatih-koc, there were quite a few replies on that thread and I didn't make it to everyone. Tim's response is what I would have said 👍

[fatih-koc]

Sorry @fatih-koc, there were quite a few replies on that thread and I didn't make it to everyone. Tim's response is what I would have said 👍

Thanks a lot @leerob We appreciate your hard work and kindly save us from this i18n troubles. We do not wish to wait for another 2 years to have such a critical feature. many kind regards from an nextjs lover and user.

[leerob]

We have published new docs on i18n inside the app directory, which should enable this use case to be solved inside Middleware: https://beta.nextjs.org/docs/guides/internationalization

[gffelisberto]

Hello there 👋🏽 and first of all, thank you everyone about the inputs on this topic here, really good insights!

Currently doing some homework and if I understood everything correctly since the begginning, at this point, there is no solution like custom-path custom-path.

The only way to achieve localized urls / internationalized path with NextJS is using the middleware strategy?

[fatih-koc]

Solved with middleware: AKA each request to your site can pay vercel for an edge invocation! $$$

wow, i never thought of this scenerio as we self host our products. They care more about $$ than to offer a true i18n like nuxt, and its unbelievable we have such a problem on a self claimed framework in the year of 2023! bruh

[branislavbrincko]

1. I still don't understand how to translate slugs using app router - let's say I need /en/products and /de/produkte.
   The request comes with german language in headers, so I will redirect the user like so:

return NextResponse.redirect(
      new URL(`/${locale}/${pathname}`, request.url)
)

to /de/produkte. But how to tell next that for /de/produkte it's supposed to render [lang]/products/page.tsx?
The only solution that comes to mind is to to have two files - [lang]/products/page.tsx and [lang]/produkte/page.tsx but that seems clunky. Or am I missing something?

2. What if I have completely static website without server (I use "output": "export" in next.config.js). In this case I CANNOT use middleware. So there is basically no recommended way how to have i18n in this situation. Or again - what am I missing?

There is loooot of talk about innovation, RSCs, and so on but I am shocked that this rather basic (and very important) functionality is so hard to achieve.

Would be grateful for any kind of help 🙏

[svobik7]

The only solution that comes to mind is to to have two files - [lang]/products/page.tsx and [lang]/produkte/page.tsx but that seems clunky.

If you decide to go that way you can use my https://github.com/svobik7/next-roots package to generate you app folder structure in a way you described. It should play well with static export too.

[kimskogsmo]

You're a god @svobik7

[DennisKraaijeveld]

So the app dir really fixed the issue with translated slugs? Or are there any caveats?

[fatih-koc]

No, offered solution is just a middleware solution currently and we are still waiting desperately or we will dump our project totally.

[leerob]

Yes, you can use the app router to translate slugs + use middleware for more customization on routing!

[neilmispelaar]

Is there a preferred sample / approach to this? I have been using my Google skills, but there are a plethora of different blog posts and packages that try to get SSG+i18n+Next done and it’s left me slightly dazed and confused.

[leerob]

I am not sure I've seen one built yet, but if you do end up exploring one, I can get it added to the docs 👍 🙏

[kimgiutae]

@leerob Hello

Can you explain a little further about cost implications in sites with medium/high multilingual traffic? Is this a good strategy to business scale? Each multilingual user visit will cause a manual redirect (server/edge-function usage)?

Dunno... this seems like a little forced solution.... Why I have to force a redirect for a lot of content I know in advance that should exists statically. I always considered redirections to very especific usecases for bad/wrong/removed/old urls to new ones.

Sincerely, seems like a general solution that takes off responsabilities of the framework and leaves most of the logic work to the developers... not to mention cost concerns.

My team was expecting a more DX friendly approach, but seems that i18n (as a whole) is not a priority topic to the core-team, and maybe it could be justified from a commercial point of view.

Please... just wanna hear your thoughts on this

Many Thanks

[leerob]

Cost depends on your infrastructure provider and the type of compute you're using. For example, if you're using Edge Functions on Vercel, it's very cost-effective as you scale.

[kimgiutae]

Hi @leerob. Thanks for the reply. Ok costs shouldn't be a (big) problem.

But... what about forcing a redirect for a lot of content I know in advance that should exists statically? What about having the runtime busy checking all that (unnecessary) rewrites? And the DX issue of having to deal with a lot of duplication of URLs with wrong languages?

Still seems like a oversimplified solution to a complex DX/SEO concern.

[fatih-koc]

Hi @leerob. Thanks for the reply. Ok costs shouldn't be a (big) problem.

But... what about forcing a redirect for a lot of content I know in advance that should exists statically? What about having the runtime busy checking all that (unnecessary) rewrites? And the DX issue of having to deal with a lot of duplication of URLs with wrong languages?

Still seems like a oversimplified solution to a complex DX/SEO concern.

why should we keep runtime busy and use middleware request/response cycle while we can have static translations and serve them directly? Good objection points for an overly simplified and half baked solution.

[leerob]

There's a reply above showing how you can translate route segments with the new structure in the App Router: #18485 (comment)

[gffelisberto]

Thank you @leerob for a clear and direct answer :)

[svobik7]

Hello there,

I finally updated my old library called next-roots to support new app folder.

It basically works as a generator for translated routes => takes all your routes and generate translated one based on your needs.

No dynamic [lang] segment, no rewrites, no middleware needed. All translated routes are stored statically.

Also it comes with typed getHref util for creating links.

Feel free to check it. Any feedback is welcome 🙂

[fatih-koc]

Finally a great way to fix what core team was not able to for 3 years! Congrats Jirka 🎉

In the past, I have used Next-translate-routes and currently developing in nuxtjs which is delight versus pain in *** nextjs way.

I have great ideas and would like to contribute more to your great plugin. First is: It would be great to define roots under pages folder with an json and yaml.

• pages
• • about
• -- routes.json
• -- about.jsx
• • news
• -- routes.json
• -- news.jsx

Also next-roots is a great name and I think naming your great fix as next-i18n-routes would be put whole dev team of nextjs in shame which they did not prefer to fix for such a long time.

In short, please know that I would like to be contributor for your project and feel free to ask me to help you in anyway to make this thing a beast! thanks a lot and lots of love.

[svobik7]

Thank you @fatih-koc ♥️ any contribution or ideas are welcome. Feel free to open issue in my repo to discuss your ideas.

[chuckcg]

Clever stuff @svobik7. This is the reply, folks.

[valse]

Hi @svobik7 congratulations you made an awesome project and it's very powerful and useful!

I'm using it in one of our apps and I'm very happy for now... Just a little annoying behavior on development mode only with the next/font loaded in the layout root; I'll open an issue for that 😉

Thanks and I hope in a similar implementation for the slug internationalization from the core team too 😜

[dennispassway]

I can't update to the app directory for my project at the moment, (if you could you should!), so I found a way to do this within the middleware within a pages app. Putting it here so it might help someone.

In my middelware.ts I check if the pathname of the url includes a part that i want to translate, and if it does i accept requests coming in on that url

export default async function middleware(request: NextRequest) {
  // Get this locale from somewhere, depending on how you structured your translation
  if (locale) {
    // Here I check if the path is translatable, to prevent the user accessing the root language urls AND the translated urls
    if (pathIncludesTranslationalPart(request.nextUrl.pathname, locale)) {
      request.nextUrl.pathname = `/404`;
      return NextResponse.rewrite(url);
    }
  
    request.nextUrl.pathname = translatePathnameToPagesPath(request.nextUrl.pathname, locale);
  }
  
  return NextResponse.rewrite(url);
}

And the functions look like this:

const PAGES_PATHS_TRANSLATIONS = {
  de: {
    kontakt: 'contact',
    suchen: 'zoeken',
  },
  pl: {
    kontakt: 'contact',
    szukac: 'zoeken',
  },
};

export function pathIncludesTranslationalPart(pathName: string, locale = 'nl') {
  const translationsForLocale = PAGES_PATHS_TRANSLATIONS[locale];

  if (!translationsForLocale) {
    return false;
  }

  return pathName.split('/').some((urlPart) => Object.values(translationsForLocale).includes(urlPart));
}

export function translatePathnameToPagesPath(pathName: string, locale = 'nl') {
  const translationsForLocale = PAGES_PATHS_TRANSLATIONS[locale];

  if (!translationsForLocale) {
    return pathName;
  }

  return pathName
    .split('/')
    .map((urlPart) => translationsForLocale[urlPart] || urlPart)
    .join('/');
}

// And this fn is used the other way around, to translate the pages path to the url path. This is what I use in href's of the app.
export function translatePagesPathToPathname(pathName: string, locale = 'nl') {
  const translationsForLocale = PAGES_PATHS_TRANSLATIONS[locale];

  if (!translationsForLocale) {
    return pathName;
  }

  return pathName
    .split('/')
    .map((urlPart) => {
      const foundTranslationForUrlPart = Object.entries(translationsForLocale).find(
        ([, orginale]) => urlPart === orginale
      );
      return foundTranslationForUrlPart && foundTranslationForUrlPart.length > 0
        ? foundTranslationForUrlPart[0]
        : urlPart;
    })
    .join('/');
}

[kamzata]

Does this solution work with (e.g.) next-sitemap? Furthermore, what's the best i18n library to use with App Router? next-international, next-intl, or... what else?

[SanjoSolutions]

In this repository you can check out, how this can be done with app router.

[brokeboiflex]

Kinda dumb solution but it works, just import the pages in localised folders and reexport them like this:

export { default as default } from "./path-to-generic-page";

[svobik7]

If you want to automate it you can use https://github.com/svobik7/next-roots package. It does the same under the hood.

[kimgiutae]

Hi ppl. After some time working with the new app router, this is my current solution to this issue preserving all static goodies and avoiding the middleware complexity or extra libs.

For example, a site with home page in english as default language, but also spanish and portuguese:

First I create a HomePage.tsx component, smth like this:

import getPageDataByLang from '@/utils/getPageDataByLang'
import getTranslationByLang from '@/utils/getTranslationByLang'
import type { PageProps } from '@/types/PageProps'
import type { FC, ReactNode } from 'react'

const HomePage: FC<HomePageProps> = async ({ lang, children }) => {
  const { title } = await getPageDataByLang(lang, 'home')
  const { currentLanguage } = getTranslationByLang(lang)
  return (
    <div>
      <h1>{title}</h1>
      <p>{`${currentLanguage}: ${lang}`}</p>
    </div>
  )
}

type HomePageProps = {
  lang: PageProps['lang'] // en | es | pt
  children: ReactNode
}

export default HomePage
export type { HomePageProps }

Second I organize the app folder like below:

app/(en)/page.tsx
app/es/page.tsx
app/pt/page.tsx

Third I export components like this on each page (example in the 'app/(en)/page.tsx' file):

import HomePage from '@/components/HomePage'

const ENHomePage = () => <HomePage lang='en' />

export default ENHomePage

(Notice that all components above are RSC)

The layout.tsx file follows the same approach, a <RootLayout /> and a <ENRootLayout /> component for each language.

The benefits that I found this way, is that now I have full control of each page in each language in a more intuitive way.

And also I really don't care of automatic redirection, I left that job for the bots/crawlers. Btw, creating a language switcher is also a piace of cake.

Of course, there must be a better way (specially for DX), but for now this is working nice to me.

Hope it helps someone.

[noblica]

This is how I've been doing it as well. Thanks for the detailed breakdown 👍

[svobik7]

You can actually generate such a file/routes structure using https://github.com/svobik7/next-roots

IMO better DX.

[kimgiutae]

@svobik7 Personally I prefer to avoid extra libs on my projects. But I'll give a try to your project, seems promising (as far I can see all logic is server-side only). Thanks for giving your code to the community.

[vladutilie]

[noblica]

Translations were not the problem, nor what this discussion is about.

I'm not sure why you're mentioning a translation library on a topic concerning internationalized routing?

[dfr-exnaton]

You don't have to use the translation features - It offers a very nice localized routing middleware. Even type safe.

[vladutilie]

Sorry, my bad.

[jimbatshetrim]

Hi everyone, I avoided the middleware solution because you can still visit the other link. I came up with this solution using rewrite and redirects. Not sure what the drawbacks would be.
in next.config.mjs

 async rewrites() {
    return [
      {
        source: "/de/yachten/",
        destination: "/de/yachts/",
      },
      {
        source: "/de/yachten/:slug",
        destination: "/de/yachts/:slug",
      },
    ];
  },

  async redirects() {
    return [
      {
        source: "/de/yachts/",
        destination: "/de/yachten/",
        permanent: true,
      },
      {
        source: "/de/yachts/:slug",
        destination: "/de/yachten/:slug",
        permanent: true,
      },
    ];
  },