Get the locale within middleware

[jamiematthews21]

In my middleware function, I'm making use of the next-intl middleware and then forwarding the response on to a second function to add some extra cookies and headers based on the user's locale.

export async function middleware(request: NextRequest) {
    const intlMiddleware = createMiddleware(routing);
    const response = intlMiddleware(request);

    // ... add cookies to response
}

What is the best way to get the user's locale in middleware? When I try and use await getLocale(), I get an error saying the function is being called from client code, which isn't the case:

Some suggestions would be appreciated 😊

[amannn]

That's a good question! The negotiated locale is currently not returned from the middleware and is only available after the middleware has finished executing (e.g. in components).

Can you tell me a bit more about your use case, i.e. what kind of response headers you'd like to add based on the negotiated locale?

As you've noticed, as a workaround you can read from x-middleware-request-x-next-intl-locale. This is a private API, but it will not be removed in a non-major version and also not as long as there's no replacement for this.

It seems like on the Next.js side there's some work happening on a new middleware architecture, so for the time being I'm trying to collect use cases that could potentially be considered if the next-intl middleware needs to be adjusted in response (see #1362).

[jamiematthews21]

Hey, thanks for responding 😊 Our current use case is we run A/B tests on our website, which we handle via setting a cookie to identify which test and variant a user has been opted into via some middleware. For some tests, we limit these to particular languages, so to know whether we can opt a user into an experiment we need to know what locale next-intl is using for them.

The x-middleware-request-x-next-intl-locale is a good work around for the moment, but I did notice that the header doesn't get set until the user has been redirected to include the locale in the URL. E.g. If I try to access a page on our site from a new browser window that doesn't include the locale url param, a redirect has to first take place to include the locale url param and that follow up request then has the x-middleware-request-x-next-intl-locale header attached.

If there's any more information I can provide about our use case that would be useful, please just let me know and thank you for taking the time to consider this 👍

[amannn]

For some tests, we limit these to particular languages, so to know whether we can opt a user into an experiment we need to know what locale next-intl is using for them.

Sounds reasonable, yes—I'd definitely like to support this use case!

I did notice that the header doesn't get set until the user has been redirected to include the locale in the URL

That's true. Do you require the locale also for redirects? The mentioned header is currently only set when no redirect is necessary and a page renders. Do you implement the A/B tests as rewrites, or redirects?

[jamiematthews21]

The A/B tests are implemented as rewrites, so I can adapt the logic where we check that the x-middleware-request-x-next-intl-locale header exists, and if it's not, we avoid doing any test assignments as we assume there will be a second follow up request that will include the x-middleware-request-x-next-intl-locale header. It doesn't add much complexity to the code, but I think it would be easier to understand if we weren't having to adapt to this.

[amannn]

Got it! Seems like for the time being the added request header can work as a workaround as far as I understand.

I'll have another look at this in the context of #1362!

[jamiematthews21]

Nice one, cheers 😊