[i18n] Prefix for default locale #18419

omgMath · 2020-10-28T20:45:08Z

omgMath
Oct 28, 2020

Feature request

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

Updated answer: Yes. The i18n-feature of next.js hides the defaultLocale in the routing, which poses the following problems:

Not ideal for SEO
Not consistent
In regions with different official or unofficial locales, the defaultLocale gets a special treatment. It implies that the defaultLocale is more important than the others, when in reality all locales should be treated equally.

Original, (too) modest answer: Not really. It would just allow the same behaviour we have with our current i18n library.

Describe the solution you'd like

I would like to ask for the feature basically proposed here: #17078 (comment) by @Vadorequest, which is to optionally enable a prefix for the default locale.

Example:
We have our site available in two languages, en and de, with en being the defaultLocale. Assume there is page home. Currently, this page would be available under /home and /de/home. It would be nice to have a configuration option so that the page would be available under /en/home and /de/home, respectively.

Describe alternatives you've considered

Note/Update: These are ideas summarized from the comments below

Use redirects? -> Causes error ERR_TOO_MANY_REDIRECTS
Introduce a fake locale, detect locale in _apps getInitialProps and redirect -> Sacrifices Static Site Generation
Introduce a fake locale, redirect to fallback locale -> See [i18n] Prefix for default locale #18419 (comment) -> Seems to work in some cases, but is kinda ugly... Plus: It takes an unnecessary redirect to arrive at where we want to end up...

Note to the community

Please refrain from posting comments like "I want this too", "+1" and so on. Instead use the ":+1:" below the issue to upvote this feature request.

Answered by leerob

Oct 30, 2021

Credit to @pecoram and @dgoerdes, we now have a solution for this in Next.js 12 with Middleware!

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

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

export async function middleware(req: NextRequest) {
  if (
    req.nextUrl.pathname.startsWith('/_next') ||
    req.nextUrl.pathname.includes('/api/') ||
    PUBLIC_FILE.test(req.nextUrl.pathname)
  ) {
    return;
  }

  if (req.nextUrl.locale === 'default') {
    return NextResponse.redirect(
      new URL(`/en${req.nextUrl.pathname}`, req.url)
    );
  }
}

// next.config.js

module.exports = {
    i18n: {
        locales: ['default', 'en', 'de', 'fr'],
        defaultLocale: 'default',
…

View full answer

mathieumagalhaes · 2020-10-28T23:59:43Z

mathieumagalhaes
Oct 28, 2020

Ideal, this should be configurable with a boolean.
If not could we have an example on how to solve this use-case?
With redirects I'm running into ERR_TOO_MANY_REDIRECTS

0 replies

brerdem · 2020-10-30T12:21:22Z

brerdem
Oct 30, 2020

+1 for this request

0 replies

Vadorequest · 2020-11-02T10:05:49Z

Vadorequest
Nov 2, 2020

FYI if there are more upvotes on the above discussion, then it'll increase the probability for it to be implemented.

Source: #18582

0 replies

davecardwell · 2020-11-02T17:48:44Z

davecardwell
Nov 2, 2020

This seem to be a fairly common pattern out in the wild, eg.:
https://www.microsoft.com/windows/ redirects to https://www.microsoft.com/en-us/windows/
https://www.mozilla.org/firefox/ redirects to https://www.mozilla.org/en-US/firefox/
https://www.minecraft.net/community redirects to https://www.minecraft.net/en-us/community

It would definitely be needed to support our own existing Next.js site which has the locale in every path:
https://www.reception247.com/en-GB/pricing
https://www.reception247.com/en-US/pricing

I considered allowing the prefixless version for our default locale (en-US) and using <link rel="canonical"> to point to the /en-US version for search engines, but that doesn’t help our regular users being redirected to the correct locale. It would be a great feature on say our social media to be able to link to eg. /pricing and have visitors automatically redirected to /en-GB/pricing or /en-US/pricing as appropriate.

1 reply

CaptainN Jun 15, 2022

Do you know how to allow a prefixless version for the default locale? In my testing, it always outputs <html lang="default">.

RobinSCU · 2020-11-11T06:04:50Z

RobinSCU
Nov 11, 2020

I made a PR with a fix for our Problem: #19035

0 replies

nephlin7 · 2020-11-18T18:49:10Z

nephlin7
Nov 18, 2020

@Timer @timneutkens,

hello guys any news on this? Could be good to have this option and avoid the redirect solution.

0 replies

lipoolock · 2020-11-25T14:59:03Z

lipoolock
Nov 25, 2020

Hi
It would be really great to have that feature activated
I saw that pipeline is still broken https://github.com/vercel/next.js/pull/19035/checks?check_run_id=1420387265
Anyone knows how to solve it ? Perhaps that's the blocker for the merge ?

0 replies

rnmhdn · 2020-12-05T21:57:16Z

rnmhdn
Dec 5, 2020

We would like to have this too.

0 replies

lotharvm · 2020-12-30T09:12:26Z

lotharvm
Dec 30, 2020

@timneutkens, is there any chance this feature and/or #19035 will be checked and implemented anytime soon? Both this post and the PR have quite some upvotes now :)

0 replies

RobinSCU · 2020-12-30T11:46:18Z

RobinSCU
Dec 30, 2020

We found a Workaround for our Project which is a bit hacky but okay for us at the moment. Basically we add a fake language and detect the language by our own.

No guarantee that the code below works :)

I added the language "fake" in the next.config as third and default language:

// next.config.js
module.exports = {
  i18n: {
    // These are all the locales you want to support in
    // your application
    locales: ['en-US', 'fr', 'nl-NL','fake'],

    // This is the default locale you want to be used when visiting
    // a non-locale prefixed path e.g. `/hello`
    defaultLocale: 'fake',

    // Real default we want to show in the URL
    realDefaultLocale: 'en-US'

    // Set LocalDetection to false so that you not get redirected to "fake" as default
    localeDetection: false
  },
}

in the _app.tsx we try to detect the language / default and redirect to them

// _app.tsx
static async getInitialProps(appCtx: AppContext) {
    await detectLanguageAndRedirect(appCtx);
    
    return {} as AppInitialProps;
}

// DetectLanguage.ts

export function detectBrowserLanguage(headers): string {
    let userLang;

    const acceptLanguagesArray = headers['accept-language']?.split(',') || [];
    if (acceptLanguagesArray && acceptLanguagesArray[0]) {
        [userLang] = acceptLanguagesArray[0]?.split('-');

        if (nextConfig.locales.some((l) => l === userLang)) {
            return userLang;
        }
    }

    return nextConfig.realDefaultLocale;
}

export function getRouteForLanguage(ctx: NextPageContext, lang: string): string {
    let route = `/${lang}`;

    const [path, query] = ctx.req.url.split('?');

    if (path !== '/') {
        route += ctx.asPath;
    } else if (query) {
        route += `?${query}`;
    }

    return route;
}

export function redirectToRoute(ctx: NextPageContext, url: string) {
    ctx.res.writeHead(302, {
        Location: url,
    });
    ctx.res.end();
}

export default function detectLanguageAndRedirect(appCtx: AppContext) {
    const langQuery = appCtx.router.locale;
    // urls with _ at the start should be next interal urls
    if (
        (nextConfig.locales.some((l) => l === langQuery) && langQuery !== 'fake') ||
        langQuery.indexOf('_') === 0 ||
        langQuery === '[...path]'
    )
        return;

    const detectedLanguage = detectBrowserLanguage(appCtx.ctx.req.headers);

    redirectToRoute(appCtx.ctx, getRouteForLanguage(appCtx.ctx, detectedLanguage));
}

1 reply

omgMath Feb 20, 2021
Author

Great idea and thanks for sharing!
In my case (and this is more towards the next.js-Team) this does not work, because the reason to upgrade to next.js v10 in the first place is to profit from the Static Side Generation, which is not possible with a getInitialProps in the _app.tsx

CyanoFresh · 2021-01-18T20:41:18Z

CyanoFresh
Jan 18, 2021

need this

0 replies

RobinSCU · 2021-01-21T21:50:02Z

RobinSCU
Jan 21, 2021

Just for information: I closed my PR because I think the implementation should be done by someone who has a deeper understanding of the i18n integration in Next.js

0 replies

tmskrtsz · 2021-01-22T07:57:22Z

tmskrtsz
Jan 22, 2021

I would benefit from having this feature too.

0 replies

martijnvanonz · 2021-01-25T14:06:35Z

martijnvanonz
Jan 25, 2021

Hi @timneutkens,

Can you give an update on this? Can we wait for this feature or are you guys not going to implement it?

0 replies

andrewfairlie · 2021-02-01T12:26:57Z

andrewfairlie
Feb 1, 2021

I have a possible alternative solution that allows you to continue to use automatic static optimization and without any custom code other than a few config lines.

Step 1: Add a `catchAll` locale and set as the default locale

This locale will never actually serve any pages (because step 2), but it will become the locale at /. If a user's browser matches one of the available locales Next will continue to be automatically redirect them accordingly.

  i18n: {
    locales: ['en', 'fr', 'catchAll'],
    defaultLocale: 'catchAll',
  },

Step 2: Setup a redirect from catchAll to your real default

I've set permanent as false here just to make debugging easier if I change it, but you can almost certainly make this true.

  async redirects() {
    return [
      {
        source: '/catchAll',
        destination: '/en',
        locale: false,
        permanent: false,
      },
      {
        source: '/catchAll/:slug*',
        destination: '/en/:slug*',
        locale: false,
        permanent: false,
      },
    ]
  },

🎉 Done!

You can now go to / and be diverted to /en, likewise /blog will be diverted to /en/blog. But if your browser is configured for fr it will divert you to /fr instead.

This has been tested locally and on Vercel and seems to work for me, but I'd really appreciate any feedback.

26 replies

vforvalerio87 Aug 20, 2021

This helped me with an issue I was having but created some new problems. Specifically, API endpoints do not work anymore on the default locale (gets redirected to //api/... and returns a 404), and next/image with images taken from the source code.

Any ideas on how to navigate around it?

rlenoir-codepoint Aug 20, 2021

Hey @andrewfairlie, adding this catchAll locale trick works, but has the side-effect of generating and including the locale files in the in the build. Do you know how we can exclude those files before the build step? Otherwise a command line rm -rf alias on the custom Vercel build command should to the trick, but if we can avoid it beforehand the build will be faster...

here alias is the catchAll in your example

martinratinaud Aug 26, 2021

This helped me with an issue I was having but created some new problems. Specifically, API endpoints do not work anymore on the default locale (gets redirected to //api/... and returns a 404), and next/image with images taken from the source code.

Any ideas on how to navigate around it?

I managed to do this by preventing redirects to handle api routes

like so

async redirects() {
    return JSON.parse(
      JSON.stringify([
        {
          source: '/catchAll',
          destination: '/en',
          locale: false,
          permanent: false,
        },
        {
          source: '/catchAll/(!api/):slug*',
          destination: '/en/:slug*',
          locale: false,
          permanent: false,
        },
      ])
    );
  },

But I think this feature should be put in top priority as well :-)

svassaux Aug 31, 2021

@martinratinaud thanks, I had the same issue!

dnbastos Sep 27, 2021

I had a problem with the 404 error page. After using i18n on the 404 page(pages/404.ts) with getStaticProps to load translations, an error happens on build, when it is pre-rendering the 404 page.
The pre-rendering of the 404 page seems to happen before the redirect to the real default, so it tries to fetch the strings from the fake locale.
The error log says:

Error occurred prerendering page "/catchAll/404"
Default namespace not found at …/locales/catchAll/common.json

Update: I simply set this in i18next config and seems to work for me:

{
   defaultNS: undefined,
}

elias-thok · 2022-04-20T13:17:08Z

elias-thok
Apr 20, 2022

This approach works well without domains.
But is there a way to provide this functionality when using domain-based routing? Because then I need this redirection on every domain and I can't have more than 1 domain with defaultLocale: "default".

So, for example, if I have a domain that covers a few languages, like *.ch. Say, I have a site with 10 domains and I want the default-locale prefixed in all of them to treat the languages equally.

Do I need then 10 placeholder locales (default-de, default-com, etc.) & a huge _middleware.ts?
Like this:

{
  domain: "my-url.com",
  defaultLocale: "default-com",
  locales: ["en-EU", "en-AU", "en-GB"]
}

Is there any better way of solving this?

1 reply

elias-thok Apr 28, 2022

So I kinda figured out a way to approach this, width a naming-convention for the default-locale.

If I have, say, 10 different domains with each having a placeholder-locale named default-xx-XX, i can automate the the redirect to the "real" default-language:

import { NextRequest, NextResponse } from "next/server"

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

/* strip the default-locale from the pathname */
const stripDefaultLocale = (pathname: string, defaultLocale: string): string => pathname.replace(`/${defaultLocale}`, "")
/* remove "default-" placeholder from locale */
const convertToDefaultLocale = (locale: string): string => locale.replace("default-", "")

/* Always redirect to a localized URL */
export function middleware(request: NextRequest) {
  const { pathname, origin, locale, search } = request.nextUrl.clone()

  /* checks for
   - public files (fonts, images, ...)
   - all /api Routes
   - the locale being set to "default"
   */
  const shouldHandleLocale = !PUBLIC_FILE.test(pathname) && !pathname.includes("/api/") && locale.startsWith("default-")
  // Constructs redirect URL with real default-language
  const redirectURL = `${origin}/${convertToDefaultLocale(locale)}${stripDefaultLocale(pathname, locale)}${search}`
  // redirects to original route with language prefixed
  if (shouldHandleLocale) {
    return NextResponse.redirect(redirectURL)
  }
  return undefined
}

shestakov-vladyslav · 2022-06-15T11:11:20Z

shestakov-vladyslav
Jun 15, 2022

I do need such a feature

0 replies

AustinShelby · 2022-06-20T13:42:11Z

AustinShelby
Jun 20, 2022

The accepted answer doesn't work when using the Edge Functions in Netlify.

I added the following changes to make it work.

// pages/_middleware.ts

import { NextRequest, NextResponse } from "next/server";

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

export function middleware(request: NextRequest) {
  if (process.env.NODE_ENV === "development") {
    const shouldHandleLocale =
      !PUBLIC_FILE.test(request.nextUrl.pathname) &&
      !request.nextUrl.pathname.includes("/api/") &&
      request.nextUrl.locale === "default";

    if (shouldHandleLocale) {
      const url = request.nextUrl.clone();
      url.pathname = `/de${request.nextUrl.pathname}`;
      return NextResponse.redirect(url);
    }

    return undefined;
  } else {
    const shouldHandleLocale =
      !PUBLIC_FILE.test(request.nextUrl.pathname) &&
      !request.nextUrl.pathname.includes("/api/") &&
      !request.nextUrl.pathname.startsWith("/en/") && // Netlify Edge Functions don't have request.nextUrl.locale so we need to manually check the path
      request.nextUrl.pathname !== "/en" &&
      !request.nextUrl.pathname.startsWith("/de/") &&
      request.nextUrl.pathname !== "/de";
    if (shouldHandleLocale) {
      const url = request.nextUrl.clone();
      url.pathname = `/de${request.nextUrl.pathname}`;
      return NextResponse.redirect(url);
    }

    return undefined;
  }
}

// next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  i18n: {
    locales: ["default", "en", "de"],
    defaultLocale: "default",
    localeDetection: false,
  },
  trailingSlash: true,
};

module.exports = nextConfig;

1 reply

igorzinar Oct 20, 2022

Thank you it was helpful
You also could detect language from request


export function middleware(request: NextRequest) {


// Find browser language
  const acceptLanguage = request?.headers?.get("accept-language")
    ? request?.headers?.get("accept-language")?.slice(0, 2)
    : null;

// Find cookies language
  const cookieLang = request?.cookies.get("lang");

  // Order of source for languages (custom language detector)
  const requestLanguage = cookieLang
    ? cookieLang
    : request?.nextUrl?.locale !== "default"
    ? request?.nextUrl?.locale
    : acceptLanguage === "ru" || acceptLanguage === "en"
    ? acceptLanguage
    : "en"; 
        
     // rest of locale logic


  if (shouldHandleLocale) {
      const url = request.nextUrl.clone();
      url.pathname = `/${requestLanguage}${request.nextUrl.pathname}`;
      return NextResponse.redirect(url);
    }
}

rebzden-baracoda · 2022-06-21T15:34:22Z

rebzden-baracoda
Jun 21, 2022

I know that everything here has been said already but I think that it should be much easier to setup, without any middleware since it breaks website logic. For example if the user changes locale to default one on purpose (which changes url to /) and refreshes the website, the app again uses browser's locale.

What we did was pretty simple (but far from ideal in my opinion), we've added 'default' language definition in i18n next to the 'en', and set it as default one as well. We've left the detectlocale set to true since it's a pretty nice feature ;). In order to receive locale in the pages where we need the information, we've made custom hook that checks if the active locale is set to 'default' and otherwise return 'en'.

For me the best option would be to add a flag that allows a user to force locale in the url.

Hope that helps someone :)

0 replies

ajmnz · 2022-07-06T14:30:03Z

ajmnz
Jul 6, 2022

Since v12.2 middleware also executes for internal requests, making all _next requests prefixed with a locale when using the accepted solution and thus assets returning a 404.

A quick solution would be to filter out those internal requests prior to any redirection

export async function middleware(req: NextRequest) {
  if (req.nextUrl.pathname.startsWith("/_next")) {
    return res;
  }

  // rest of locale logic
}

4 replies

magsout Jul 6, 2022

Yes good point. Exemple is not up to date in this case https://nextjs.org/docs/advanced-features/i18n-routing#prefixing-the-default-locale

leerob Jul 7, 2022

Thanks! Will fix.

leerob Jul 7, 2022

#38419

magsout Jul 7, 2022

@leerob thanks

11koukou · 2022-07-06T20:47:09Z

11koukou
Jul 6, 2022

I can't imagine why it would be so difficult to optionally enable force default locale prefix in the url, it is a much requested feature and the accepted solution with the middleware introduces unnecessary complexity and even drops performance. I can understand that maybe that feature needs a lot of work and re-coding but I would wish someone to state that.

I am going to open a new feature request discussion mentioning this in case that this one here is no longer being monitored due to having the "answered flag". ( #38387)

0 replies

gregghawes · 2022-08-14T14:47:59Z

gregghawes
Aug 14, 2022

Is there any way to do this the opposite way, so that the defaultLocale can only be loaded on the domain and not as well in a subfolder?

domain.com - defaultLocale
domain.com/defaultLocale/ - either 404's or 301 redirects to domain.com

4 replies

rebzden-baracoda Sep 19, 2022

have you tried this? #18419 (comment)

mderrick Dec 20, 2022

Did you solve this? The sub-path routing docs say:

The default locale does not have a prefix.

Yet my defaultLocale exists under two URL's as you describe. Is the answer to simply add some sort of redirect? Like this:

  {
      "source": "/en/:path*",
      "destination": "/:path*",
      "permanent": false
    }

I also raised this question on Stack Overflow about this issue.

gregghawes Jan 3, 2023

I didn't manage to solve it, I asked in a few different places but didn't get any helpful response. I couldn't get the redirect to work consistently. Does that work for you?

mderrick Jan 3, 2023

No the redirect would send me in an infinite loop so I'm stuck with having duplicate URL's and using a canonical and robots.txt to ignore all /en paths. Not ideal at all.

anders-photowall · 2022-09-19T12:04:41Z

anders-photowall
Sep 19, 2022

So using the suggested middleware in the docs https://nextjs.org/docs/advanced-features/i18n-routing#prefixing-the-default-locale actually breaks any statically generated pages for me but only if they are deployed to Vercel.

All paths I return from getStaticPaths first renders correctly, but an instant later I get a client side re-render where none of my props supplied by getStaticProps are defined. The paths that are not returned from getStaticPaths however works as they should. They are generated on request and after that I can still access them without errors (this time fast, as they are now generated).

After digging quite a bit it seems it could be related to what is returned by the
"https://{host}/_next/data/{hash}/{locale}/{route-slug}.json" GET request which is fired by the browser on each page. On my local machine (after yarn build, yarn start) this returns all data needed to render the page. On Vercel it just returns empty object for all routes. This includes the routes that work though (the ones not returned by getStaticPaths). But it seems only the pages that were actually generated build time tries to use that data on a re-render? I'm confused.

If I remove the middleware everything works as it should again, except I don't get the wanted redirect for default locale.

5 replies

anders-photowall Oct 10, 2022

I'm waiting for a response from the Vercel team about this, but I did isolate this issue to the combination of three things:

The middleware we discuss here to get prefixed default locale
Rewrite rule that in my case looks rewrites /:productPageSlug-localisedProductType to /product/productType/:productPageSlug
getStaticPaths function that returns locale together with params for the path.

If I remove just one of these I do not get the undefined props on Vercel.

anders-photowall Oct 19, 2022

So for anyone stumbling upon this same issue I finally was able to resolve it with the help of Vercel support and a minimal reproduction repository. Apparently the use of "rewrites" in next.config.js + middleware + i18n routing can cause different configurations to overwrite each other internally in the i18n router. The solution is to either supply the rewrites as an object instead of an array and use "beforeFiles" for the rewrites or to do the rewrites inside the middleware and not do it at all in the next config.

If someone with more knowledge of the rewrite/routing internals could explain exactly why in detail (especially why it works locally but no on Vercel) that'd be great but at least this is the solution if it happens to you as well.

actraiser Oct 19, 2022

Could you kindly provide a demo or some code snippets of the solution?

Greets
-act

dennisdittrich Oct 27, 2022

also intrested in solution. run into the same problem.

anders-photowall Oct 28, 2022

In the end the simple, but perhaps the not optimal solution, was just changing the rewrite config from an array to an object in which the rewrites were specified as "beforeFiles" as I noted above, but here's the example code as well:

That is when changing next.config.js from

...
  rewrites: async () => {
    return [
      {
        source: `/:productPageSlug((?:.+)-(?:${Object.values(
          siteConfig.i18n.languages
        )
          .map((langConf) => langConf.productPathSuffix.productType1)
          .join("|")})$)`,
        destination: "/product/productType1/:productPageSlug",
      },
      {
        source: `/:productPageSlug((?:.+)-(?:${Object.values(
          companyConfig.i18n.languages
        )
          .map((langConf) => langConf.productPathSuffix.productType2)
          .join("|")})$)`,
        destination: "/product/productType2/:productPageSlug",
      },
    ];
  },
...

to

...
    rewrites: async () => {
      return {
        beforeFiles: [
          {
            source: `/:productPageSlug((?:.+)-(?:${Object.values(
              siteConfig.i18n.languages
            )
              .map((langConf) => langConf.productPathSuffix.productType1)
              .join("|")})$)`,
            destination: "/product/productType1/:productPageSlug",
          },
          {
            source: `/:productPageSlug((?:.+)-(?:${Object.values(
              siteConfig.i18n.languages
            )
              .map((langConf) => langConf.productPathSuffix.productType2)
              .join("|")})$)`,
            destination: "/product/productType2/:productPageSlug",
          },
        ],
      };
    },
...

things started working correctly again. As I wrote I do not fully understand why though 🤷‍♂️

However, the better solution is likely skipping the rewrite config completely and instead handle rewrites in the middleware. That would also give better control so that only one productPathSuffix is valid for each locale, the rewrite config above makes all the different localised product path suffixes valid on all locales.

leerob · 2023-01-08T22:14:48Z

leerob
Jan 8, 2023

If you're interested in handling this in the app/ directory, we've published documentation on Internationalization (i18n). Please leave feedback on the page! 🙏

https://beta.nextjs.org/docs/guides/internationalization

4 replies

joggienl Jan 11, 2023

Even though the new app/ directory method has more flexibility in "solving" this issue, it also seems like having a prefix is kinda the better way of doing it? Or is there also a way to make the "old" way possible, to not have the defaultLocale as a prefix?

MartinDavi Mar 24, 2023

That's great to hear, but app/ isn't ready for prime time. Is there any plan to make this a configuration option rather than the hacky workarounds suggested in this thread? Would love to see this get first class support.

leerob Mar 25, 2023

It will very soon be ready for prime time 😄 I don't view it as a hacky workaround, but as giving you flexibility. This change to i18n was based on a lot of feedback from folks using it inside pages/. We might re-evaluate or change in the future.

belafonte Apr 19, 2023

The middleware approach with the new app directory works great but crawlers have issues with it, because the root domain directly gets redirected.

So all locale domains are not crawlable. I added a sitemap with a robots.txt, which works somehow, but not sure if it is the best approach.

I followed this sample: https://github.com/vercel/next.js/tree/canary/examples/app-dir-i18n-routing would be nice to have this covered in there, to see best practices when doing like so.

EDIT: Still not working. When starting a crawler from my google account it does not work because of a 500 Error.

cdpark0530 · 2023-04-12T00:46:23Z

cdpark0530
Apr 12, 2023

@jamimeson @ajmnz @RazaGR @talatkuyuk @santyas @PascalPixel @angeloreale @elias-thok @AustinShelby @igorzinar
In your examples, I found that you clone() nextUrl. Can anyone tell me why?

I'm asking this because I'm not aware of what Nextjs does with the returned NextResponse instance, and in locales middleware from Nextra somehow modifies the nextUrl.locale and nextUrl.locale of original request, which I don't know if it's intented.

0 replies

AssisrMatheus · 2023-05-30T17:55:23Z

AssisrMatheus
May 30, 2023

The solution presented here and also on https://nextjs.org/docs/app/building-your-application/routing/internationalization doesn't work if you're incrementally adopting the /app folder.

I'm using /pages folder with a following next.config.js:

i18n: {
    locales: ['catch', 'en', 'fr'],
    defaultLocale: 'catch'
},

And a check/redirect on middleware to send the user to the according /en etc route.

So, we don't have a pages/[locale] or pages/[lang] folder to handle locale BUT, with the /app folder, the locale is handled by a [lang] root folder.

But since under /pages we don't have that but actually the first parameter that we need for our app, unrelated to locale. I get the following error:

throw new Error("You cannot use different slug names for the same dynamic path ('" + previousSlug + "' !== '" + nextSlug + "').");

Which makes sense, because they're not the same, since on /app it's [lang] and on /pages it's [slug]. But this error blocks us to incrementally adopt the /app folder since the localization methods of either don't work with each other

2 replies

vinnycodes Aug 15, 2023

Seconding this as well.
Finding the same issue as we look to incrementally adopt the app folder structure.

gadicc Aug 22, 2023

Would be absolutely amazing if someone can create a minimal reproduction of this and open an issue. I started opening a issue but the reproduction is a requirement and I'm way over time budget, unfortunately :/

StynV · 2023-08-17T12:56:02Z

krszktc · 2024-05-11T16:30:12Z

krszktc
May 11, 2024

The topic is pretty old but looks to be still alive so let me share very simple work around :)

Calling http://your.domain.com/ will use your default language. For other language for example http://your.domain.com?lang=de;

page.tsx

export default function Home({ searchParams }: { searchParams: Record<string, string> }) {
  const dictionary = await getDictionary(searchParams);

  return (...);
}

dictionary-config.ts:

const dictionaries = {
  de: () => import('./dictionaries/de.json').then((module) => module.default),
  en: () => import('./dictionaries/en.json').then((module) => module.default),
};

export type Locale = keyof typeof dictionaries; 

export const getDictionary = async (params: Record<string, string>) => {
  const paramLanguage = params['lang']?.toString() ?? '';
  const lang = paramLanguage in dictionaries
    ? paramLanguage
    : DEFAULT_LANGUAGE

  return await dictionaries[lang as Locale]();
}

If you need the value for example in layout which has no access to query parameters then:

middleware.ts:

export function middleware(req: NextRequest) {
  const lang = req.nextUrl.searchParams.get('lang') ?? ''
  const requestHeaders = new Headers(req.headers);
  requestHeaders.set('query-params-lang', lang);

  return NextResponse.next({
    request: { headers: requestHeaders }
  })
}

lauout.tsx:

export default async function RootLayout(...)
  const lang = headers().get('query-params-lang') ?? '';
  const dictionary = await getDictionary({ lang });

  return (...);
}

Remember to rename router structure from [lang] to (route) or something similar.

0 replies

ibanlopez · 2024-08-06T08:52:55Z

ibanlopez
Aug 6, 2024

Who recommends that in the first place?

It's insane: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#:~:text=Avoid%20automatically%20redirecting%20users%20from%20one%20language%20version%20of%20a%20site%20to%20a%20different%20language%20version%20of%20a%20site.%20For%20example%2C%20don%27t%20redirect%20based%20on%20what%20you%20think%20the%20user%27s%20language%20may%20be.%20These%20redirections%20could%20prevent%20users%20(and%20search%20engines)%20from%20viewing%20all%20the%20versions%20of%20your%20site.

And again: very clear: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#:~:text=If%20you%20prefer%20to%20dynamically%20change%20content%20or%20reroute%20the%20user%20based%20on%20language%20settings%2C%20be%20aware%20that%20Google%20might%20not%20find%20and%20crawl%20all%20your%20variations.

0 replies

iamhuynq · 2025-03-17T04:56:00Z

iamhuynq
Mar 17, 2025

the better version for me

if (req.nextUrl.locale === 'default') {
            let pathname = req.nextUrl.pathname;
            const cleanPath = pathname === '/' ? '' : pathname;
            return NextResponse.redirect(
                new URL(`/en-us${cleanPath}${req.nextUrl.search}`, req.url)
            );
}

0 replies

Uh oh!

[i18n] Prefix for default locale #18419

Uh oh!

Uh oh!

Feature request

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

Describe the solution you'd like

Describe alternatives you've considered

Note to the community

Replies: 51 comments · 134 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

omgMath Feb 20, 2021 Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Step 1: Add a catchAll locale and set as the default locale

Step 2: Setup a redirect from catchAll to your real default

🎉 Done!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 51 comments 134 replies

omgMath Feb 20, 2021
Author

Step 1: Add a `catchAll` locale and set as the default locale