Error: Unable to find next-intl locale, have you configured the middleware?`

[4Furki4]

Hi All !

I'm having a weird issue today that might be caused by next-intl. When I run my application both in the dev and prod build, I see this error in my console:

The weird thing is that this error shows up only in my laptop and it's like an infinite loop! I have a team with 4 people, all of us tested to run the application and nothing is thrown and Vercel deployment is working actually.

---

Here's my middleware:

---

What I tried to solve it?

• Deleting my project from local and re-clone it.
• recreating my middleware file which doesn't make sense at all bc I've never changed my middleware

What might cause this error and how can I solve it ?

[RaenonX]

@amannn Pinging to bring up attention because I encountered the same issue.

What I discovered was that, there is actually some production request http://localhost:3000/apple-touch-icon-120x120.png happening. Somehow the matcher catches it, therefore giving this error.

The issue is that if I make the matcher matcher: ['/((?!api|_next|(?:[.-]*)\\..*).*)'], instead, favicon.ico will also be inaccessible for some reason.

Not sure if this got any solution for now unfortunately, I am out of ideas of changing the matcher so that these apple icons will be excluded.

[RaenonX]

@amannn Sorry for pinging again. Wanted to bring up attention because this is creating lots of false-negative in the error logs.

[amannn]

Without a reproduction, this is unfortunately not really actionable. If you can provide a minimal reproduction, please open a bug report and I'll look into it. As you've probably seen, there's a working example in the docs which can be used as a reference implementation when in doubt. Let me know how it goes!

[RaenonX]

Got it. I can't tell what went wrong yet but my app is showing a whole blank page for /apple-touch-icon-120x120.png while the sample app is showing the deault error page :/

Checking deeper tho

[RaenonX]

I think I actually used other version (could be older?) of the example, because the layout in the sample app you gave is so off from mine.

[lorenzoa7]

I'm getting the same error here.

[kjavier]

The working example provided uses NextIntlClientProvider.

We are not using that and instead, we follow the one here:
https://github.com/amannn/next-intl/blob/feat/next-13-rsc/

I think this version is the one causing us problems.

[kjavier]

The problem is this file: https://github.com/amannn/next-intl/blob/feat/next-13-rsc/packages/next-intl/src/server/getLocaleFromHeader.tsx

For some reason, the cookies don't get set ALL THE TIME and this raises an error.

if (!locale) {
    throw new Error(
      process.env.NODE_ENV !== 'production'
        ? 'Unable to find `next-intl` locale, have you configured the middleware?`'
        : undefined
    );
  }

Instead of raising an error, why not just return the default locale or get the cookies like this?
vercel/next.js#49444 (comment)

The issue stems from this problem in nextjs vercel/next.js#49442.

[amannn]

why not just return the default locale or get the cookies like this?

It could result in the wrong locale being used, which would be a bug. I think we should really get to the bottom of this.

The issue stems from this problem in nextjs vercel/next.js#49442.

In the issue the developer is using response.cookies.set(…)—notably the response. I don't think that's a bug. See also this comment: vercel/next.js#49442 (comment)

In case the user doesn't have a cookie set yet (or it needs to be updated), we set a request header:

next-intl/packages/next-intl/src/middleware/middleware.tsx

Lines 128 to 133 in ab48fd2

	if (hasOutdatedCookie) {
	responseInit.request.headers = new Headers(
	responseInit.request.headers
	);
	responseInit.request.headers.set(HEADER_LOCALE_NAME, locale);
	}

… which is then read during the RSC render:

next-intl/packages/next-intl/src/server/getLocaleFromHeader.tsx

Lines 11 to 14 in ab48fd2

	const requestHeaders = headers();
	if (requestHeaders.has(HEADER_LOCALE_NAME)) {
	locale = requestHeaders.get(HEADER_LOCALE_NAME);
	} else {

---

Since you seem to observe different behavior when running in development or when running the app in production (as far as I understand), there might be something else happening here.

If you can provide a minimal reproduction, please open an issue so I can investigate.

[kjavier]

The problem is it is hard to reproduce. I am not having the issue but a lot of our users are. And this is the same thing experienced by the main author of this discussion. He is the only one experiencing this error among his teammates. We could not determine how we can reproduce it. @4Furki4 are you able to determine the cause?

[amannn]

Update Dec 12, 2023: If you're still encountering this error, there's a troubleshooting section in the docs now.

---

I've worked on a PR that could address this, please see the supplemental info here: #506

Since this doesn't seem to have any downsides, I've released it as next-intl@3.0.0-beta.17. Can you have a look to see if it solves the issue you're seeing?

[kjavier]

Thanks! It seems like that would fix the issue. @pogran @RaenonX @lorenzoa7 @4Furki4 Would you be able to use next-intl@3.0.0-beta.17 on your applications? I still have to wait for our internal package repository to download the next-intl@3.0.0-beta.17 release before I can use it in our production. If you dont mind, please comment if the release fixes the issue.

[4Furki4]

I've just updated the package to next-intl@3.0.0-beta.17 and tested the middleware that was causing the issue on my side. It doesn't throw any errors and seems working seamlessly.

Thank you @amannn <3

[amannn]

🤝

[pogran]

@amannn in logs I have the same errors after update module to new version. my middleware

import createMiddleware from 'next-intl/middleware'
import { NextRequest, NextResponse } from 'next/server'

export default async function middleware(request: NextRequest) {
  const handleI18nRouting = createMiddleware({
    locales: ['ru'],
    defaultLocale: 'ru',
  })
  const response = handleI18nRouting(request)

  if (
    process.env.NEXT_PUBLIC_ENV_IS_MAINTENANCE === 'true' &&
    request.nextUrl.pathname !== '/maintenance'
  ) {
    return NextResponse.redirect(new URL('/maintenance', request.url), 302)
  }

  if (
    process.env.NEXT_PUBLIC_ENV_IS_MAINTENANCE !== 'true' &&
    request.nextUrl.pathname === '/maintenance'
  ) {
    return NextResponse.redirect(new URL('/', request.url), 302)
  }

  // https://nextjs.org/docs/pages/api-reference/functions/next-server#nextrequest

  // // Step 3: Alter the response

  return response
}

export const config = {
  // Skip all paths that should not be internationalized
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico|apple-touch-icon.png|favicon.svg|images/books|icons|manifest).*)',
  ],
}

and logs

package.json

[RaenonX]

I forgot what template I was using but using old/unupdated example is the issue.

…

On Thu, Sep 7, 2023, 5:42 PM Karren Rebosura ***@***.***> wrote: The working example provided uses NextIntlClientProvider. We are not using that and instead, we follow the one here: https://github.com/amannn/next-intl/blob/feat/next-13-rsc/ I think this version is the one causing us problems. — Reply to this email directly, view it on GitHub <#446 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMW3XZLZ4PMTSZIL33F4VDXZJSX5ANCNFSM6AAAAAA3IRSYVE> . You are receiving this because you commented.Message ID: ***@***.***>

[kjavier]

Could it be the cause of this bug is this vercel/next.js#49442

[MariuzM]

I'm on 3.0.0-beta.17 and "next": "13.4.19", still issue persists

[nicole0707]

You have to set up X-NEXT-INTL-LOCALE header in middleware and it will be consumed in server components.

[pogran]

imposible to find this bug... it reproduce in real project with big count of users. i also can't reproduce this in localhost, but in prod i have a lot of this errors

[LHCLYT]

I’ve been testing in prod too, with the same errors. I didn’t find anything.

[LHCLYT]

#446 (reply in thread)

[amannn]

Maybe you can add logging and capture the whole request object in the middleware when the error occurs?

[nicole0707]

https://github.com/amannn/next-intl/blob/feat/next-13-rsc/packages/next-intl/src/server/getLocaleFromHeader.tsx#L9 It checks X-NEXT-INTL-LOCALE header now, if header isn't found, it will complain Unable to find next-intl locale, have you configured the middleware?

[pogran]

You have to set up X-NEXT-INTL-LOCALE header in middleware and it will be consumed in server components.

i need to set up this x-next-intl-locale with nginx?

[nicole0707]

We add the header in Next Middleware, because we use Middleware chain and have to manually check and add header for some scenarios.

[scerelli]

I have the same error, i don't understand what should I do. should it work without any workaround in beta 17? or am I missing something?

This is the log of my middleware

middleware log: {
lms:dev:   cookies: ResponseCookies {},
lms:dev:   url: '',
lms:dev:   body: null,
lms:dev:   bodyUsed: false,
lms:dev:   headers: {
lms:dev:   x-middleware-override-headers: 'accept,accept-language,connection,cookie,dnt,host,referer,sec-fetch-dest,sec-fetch-mode,sec-fetch-site,upgrade-insecure-requests,user-agent,x-forwarded-for,x-forwarded-host,x-forwarded-port,x-forwarded-proto,x-invoke-path,x-invoke-query,x-middleware-invoke,x-next-intl-locale',
lms:dev:   x-middleware-request-accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8',
lms:dev:   x-middleware-request-accept-language: 'en-US,en;q=0.5',
lms:dev:   x-middleware-request-connection: 'close',
lms:dev:   x-middleware-request-cookie: 'sb-...; NEXT_LOCALE=it',
lms:dev:   x-middleware-request-dnt: '1',
lms:dev:   x-middleware-request-host: 'localhost:3000',
lms:dev:   x-middleware-request-referer: 'http://localhost:3000/courses',
lms:dev:   x-middleware-request-sec-fetch-dest: 'document',
lms:dev:   x-middleware-request-sec-fetch-mode: 'navigate',
lms:dev:   x-middleware-request-sec-fetch-site: 'same-origin',
lms:dev:   x-middleware-request-upgrade-insecure-requests: '1',
lms:dev:   x-middleware-request-user-agent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0',
lms:dev:   x-middleware-request-x-forwarded-for: '::ffff:127.0.0.1',
lms:dev:   x-middleware-request-x-forwarded-host: 'localhost:3000',
lms:dev:   x-middleware-request-x-forwarded-port: '3000',
lms:dev:   x-middleware-request-x-forwarded-proto: 'http',
lms:dev:   x-middleware-request-x-invoke-path: '',
lms:dev:   x-middleware-request-x-invoke-query: '',
lms:dev:   x-middleware-request-x-middleware-invoke: '1',
lms:dev:   x-middleware-request-x-next-intl-locale: 'it',
lms:dev:   x-middleware-rewrite: 'http://localhost:3000/it/courses'
lms:dev: },
lms:dev:   ok: true,
lms:dev:   redirected: false,
lms:dev:   status: 200,
lms:dev:   statusText: '',
lms:dev:   type: 'default'
lms:dev: }
lms:dev: - error ../node_modules/.pnpm/next-intl@3.0.0-beta.17_next@13.4.7_react@18.2.0/node_modules/next-intl/dist/esm/server/getLocaleFromHeader.js (1:578) @ eval
lms:dev: - error Error: Unable to find `next-intl` locale, have you configured the middleware?`
lms:dev:     at RootLayout (./src/app/[locale]/layout.tsx:36:73)
lms:dev:     at async Promise.all (index 0)

I also tried this:

import createMiddleware from 'next-intl/middleware'
import type { NextRequest } from 'next/server'
export default async function middleware(request: NextRequest) {
  const handleI18nRouting = createMiddleware({
    locales: ['it'],
    defaultLocale: 'it',
  })

  const response = handleI18nRouting(request)
  console.log('middleware log:', response)
  response.headers.set('X-NEXT-INTL-LOCALE', 'it')
  return response
}

export const config = {
  // Skip all paths that should not be internationalized
  matcher: ['/((?!api|_next|.*\\..*).*)']
}

same stuff as someone was suggesting but same story

[pogran]

i drop this module (temporary) from my project and it starts to work 2x faster. I think module have big problem with performance if you have some audience in project

[amannn]

Would be curious to hear what kind of performance issues you're seeing in your app.

https://next-intl-example-next-13.vercel.app/ currently has a PSI performance score of 100 from what I can see: https://pagespeed.web.dev/analysis/https-next-intl-example-next-13-vercel-app/qhsh1myjli?form_factor=mobile

The adapted example in the RSC branch has the same score: https://pagespeed.web.dev/analysis/https-next-intl-example-next-13-git-feat-next-13-rsc-next-intl-vercel-app/powwa1foek?form_factor=mobile

[pogran]

@amannn yes, i think this connect with this error in this disscussion and workload. I also have this errors and mb that why i have some trobles with my site (but its fact that my users told me that site now works much better). That also fact i have 1-4 errors per 30sec - 1min. I think this error can be found with workload because i also can't reproduce it in my localhost but in prod i have a lot of this errors

[amannn]

Would be interesting if you could reproduce the bug with an HTTP load generator like oha.

My results for example-next-13 in the RSC branch locally (uses dynamic rendering currently):

After an upgrade to Next.js 13.5.1:

Next.js 13.5.1 generally includes many bug fixes, maybe this improves your situation too!

[amannn]

On top of that, there's now support for static rendering in the RSC integration, maybe that helps to reduce the load on your server too: static rendering docs.

Benchmark results with static rendering:

[LHCLYT]

I have managed to find out where these errors come from and why they only appear in production!

It is because of the 404 page. The pages not having 404 specifically created, it loads the one that has next by default, and that... makes the function jump.

It comes out in production because we constantly have crawlers that try to access wp-admins...

@amannn

[MariuzM]

can you try latest next version, i think they dont have 404 in pages dir anymore

[MatheoElieG]

I managed to fix the error in my console since we do not have a better solution yet and it was getting me cary to see all thoes errors.

This is my src/app/[locale]/layout.tsx:

import { ReactNode } from 'react';
import { notFound } from 'next/navigation';
import { headers } from 'next/headers';
import { useLocale, useMessages } from 'next-intl';

interface LocaleLayoutProps {
    children: ReactNode;
    params: {
        locale: string;
    };
}

export default function LocaleLayout({ children, params }: LocaleLayoutProps) {
    const header = headers();
    const localeHeader = header.get('x-next-intl-locale');
    if (localeHeader === null) {
        notFound();
    }

    const locale = useLocale();
    const messages = useMessages();

    // Validate that the incoming `locale` parameter is a valid locale
    if (params.locale !== locale) {
        notFound();
    }

    // ... rest of the code

}

Translations just works the same, but on the same request header without x-next-intl-localesomehow reaches the layout which should not happened since I have the middleware.

For debug purpose here is my headers list for a "healthy" request and an "unhealthy" request:

healthy (with x-next-intl-locale):

host localhost:3000
connection keep-alive
sec-ch-ua "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"
sec-ch-ua-mobile ?0
user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
next-url /
sec-ch-ua-platform "macOS"
accept */*
sec-fetch-site same-origin
sec-fetch-mode cors
sec-fetch-dest empty
referer http://localhost:3000/
accept-encoding gzip, deflate, br
accept-language fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cookie next-auth.csrf-token=b9344ee4ceae2e7ffecce7efbae4f8227b47149bf3fac7487cbc1f02be1f9a11%7Cddc02b08ce377ee779adfb8a18ede6b553a75658034df525206550f65962a1a0; NEXT_LOCALE=en; next-auth.callback-url=http%3A%2F%2Flocalhost%3A3000%2F%3Fauth-dialog%3Dsignin; next-auth.session-token=eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..KRO8CB0FouFZeO_A.kUgIWlrZRrulTp6_I7vtIKIS2RJ0BNM1iaXWZv5kNvgmsMkFrzD_3MLekiKLQXl857KnB_t1GLamJqoRF1UZOrOWQBMfG9SJ-IpMUUS0BY8AsRVSAs-xXlNQIDkJJWKIX7AhMLgkJt9k7rR-W7GEeOkqeHZMwLaZByA0PM8onwth-WIWYEFj46S93nUm6d0hW34MEBtgDJuX0v1sN4iStCy5BaZfu1xLI-NGqxGKgNQJ0cHACJjscFFFthpB0ee2UODBVngSe-Do1efLsrhfBnpK4uUd_W6fswzloc3EI-E_j_dwLzMsKZZaJQywKBDUz6bqAWF-U94.uzU55gofEOKJ7_HCCelBFw
x-next-intl-locale en
link <http://localhost:3000/>; rel="alternate"; hreflang="en", <http://localhost:3000/fr>; rel="alternate"; hreflang="fr", <http://localhost:3000/>; rel="alternate"; hreflang="x-default"

unhealthy:

host localhost:3000
connection keep-alive
pragma no-cache
cache-control no-cache
sec-ch-ua "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"
sec-ch-ua-mobile ?0
user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
sec-ch-ua-platform "macOS"
accept image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
sec-fetch-site same-origin
sec-fetch-mode no-cors
sec-fetch-dest image
referer http://localhost:3000/fr
accept-encoding gzip, deflate, br
accept-language fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cookie next-auth.csrf-token=b9344ee4ceae2e7ffecce7efbae4f8227b47149bf3fac7487cbc1f02be1f9a11%7Cddc02b08ce377ee779adfb8a18ede6b553a75658034df525206550f65962a1a0; next-auth.callback-url=http%3A%2F%2Flocalhost%3A3000%2F%3Fauth-dialog%3Dsignin; NEXT_LOCALE=fr; next-auth.session-token=eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..oOqccYa_nIGzaZOU.l5F74eL_mUeW0qMwszFRTNufN_FCC79KLkBg2wz2xphrWgqUfprBQNgEyfTO8nEklWgSoDuInCuQ9JJ6-3IysQ4-XJdG5i3-oYzeUEyO5MlsCAoDX1jmY15rGQsqL8YAkCIX_cSvkKZ8theUfVr0V-pIggMpHnWYcQfdF-uZF_kV4mOXZ9r3KRgpIIDShB3CXfQ00xjtaNIyeZWOB4pPFf1cMR780R5-HZc9EDAj9UWrKGoKVJghXJBD4Mfh9B8TbZJQQDFPDZBeWSCa1Eq9xrCEicaRu8_K3vOGBYsCVzgsr6O0b5MuHWiBkEJoOrA0hZreLA2rMpA.nouOqkA6VHMuC13fS_3a1A

I tried to disable my extensions, nothing changed.
I feel like it only happens when I reload by pressing ctrl f5 (clearing cache)
Maybe header is not correctly populated when cache has just been cleared ?

[amannn]

Thanks for sharing the details! Based on your logs, the "unhealthy" request looks for an image (given the accept header). Have you configured the middleware to ignore images? In that case, if the image doesn't exist, the request will end up with an image file being the locale param (e.g. image.png).

See also the matcher config docs.

[MatheoElieG]

Yes my middleware does ignore images since they are located under _next/....
This is my middleware:

import createMiddleware from 'next-intl/middleware';

export default createMiddleware({
    // A list of all locales that are supported
    locales: ['en', 'fr'],

    // If this locale is matched, pathnames work without a prefix (e.g. `/about`)
    defaultLocale: 'en',
});

export const config = {
    // Skip all paths that should not be internationalized. This example skips the
    // folders "api", "_next" and all files with an extension (e.g. favicon.ico)
    matcher: ['/((?!api|_next|.*\\..*).*)'],
};

[amannn]

Hmm, I see. Do you have a URL for the "unhealthy" request above? I don't find a "next-url" there.

[MatheoElieG]

Ok thank you for your time and I'm sorry for bothering you.
I changed my layout to output the params.locale in case of error, and as you just mentioned in the documentation, when the error occurs, my params.locale is equal to favicon.ico. But why does it happens since I just the recommended matcher that excluse all files with dots ?

export const config = {
    // Skip all paths that should not be internationalized. This example skips the
    // folders "api", "_next" and all files with an extension (e.g. favicon.ico)
    matcher: ['/((?!api|_next|_vercel|.*\\..*).*)'],
};

Edit; I found out that I deleted the default favicon.ico from the default nextjs template. I tried to add it again, and the error disapeared. I guess it as something to do with the notFound error when I delete it, but I don't understand why nextjs try to find it since I don't have anything related to it in my code

[amannn]

There's a new troubleshooting section in the docs in regard to this error: https://next-intl-docs.vercel.app/docs/routing/middleware#unable-to-find-locale.

It will also be linked to from the "Unable to find next-intl locale" message in the next beta release.

[truong0vanchien]

As far as I know, this cause when you have a dot sign "." in your url string, the request will not go to middleware where we set next-intl locale. I was facing the same error, then I just manually change "." to "DOT" which is quite more friendly for a url string.

[jovand3v]

If anyone is still having this issue check if you've put the middleware file in the right place. As stated in the Next.js docs.

Use the file middleware.ts (or .js) in the root of your project to define Middleware. For example, at the same level as pages or app, or inside src if applicable.

[FilFarEu]

I was figuring this out for 3 hours.. my problem was that in middleware.js I had:

export const config = {
  matcher: ['/((?!api|_next|_vercel|.*\\..*).*)']
};

and I had to change it to:

export const config = {
  matcher: ['/((?!api|_next|_vercel\\..*).*)']
};

My problem was that I wanted to create 404 error file to customize it by myself..
http://localhost/randomstring - was working and throwing 404
http://localhost/random.string - was throwing big error and page was not visible at all

So only "." - dot I needed to remove to actually catch it right.

This was only my case.

[MichalMoravik]

Changing your matcher according to this comment will malfunction any place where you use static files straight from your /public folder.

As I use quite a few of these (mostly svgs), I had to revert back to the old matcher and for now live with the fact that that will trigger the Error Boundary.

[ChiuMungZitAlexander]

Got this error by using src path. Solved by using app path. 👀👀

[dersimoezdag]

Can you provide some details? I don't know what exactly you've changed

[ChiuMungZitAlexander]

import createMiddleware from "next-intl/middleware";

export default createMiddleware({
  // A list of all locales that are supported
  locales: ["en", "zh"],

  // If this locale is matched, pathnames work without a prefix (e.g. `/about`)
  defaultLocale: "en",
});

export const config = {
  // Skip all paths that should not be internationalized. This example skips
  // certain folders and all pathnames with a dot (e.g. favicon.ico)
  matcher: ["/((?!api|_next|_vercel|.*\\..*).*)"],
};

Middleware and file structure above works for me.

[dersimoezdag]

I get the same error with next@13.5.1 and 3.0.0-beta.19

[MrSchnitz]

For me the issue was that I had messages folder called translations instead

[IRediTOTO]

F* this error, it made me all days to fix just for translation :) Now I uninstall package

[amannn]

There was an update to this in #742: next-intl will now call notFound() for these cases and therefore no error will be thrown anymore. A dev-only warning will still be printed though. Please still make sure that your middleware matcher is set up correctly. Have a look at the PR for details!

[MichalMoravik]

This is great, works like a charm! Thank you so much!

I suggest other people to check the middleware.ts in the docs examples. Specifically this was changed one week ago and served as a great example for my case.

[CarrettaRiccardo]

For me the problem was that I was using withHydrationOverlay in next.config.mjs from the package @builder.io/react-hydration-overlay, and somehow that interferes with next-intl