What's the suggested way to set the locale with the app directory without using paths?

[finkrer]

It really surprises me that everyone's only talking about setting locales like site.com/en/whatever. In our app, we are using a cookie, which seems to be a pretty common thing.

With the pages directory, I could just take the context in getServerSideProps, determine the necessary locale, then do context.locale = 'language', and it worked.

Now it seems like there's no such thing as context anymore. I can get cookies, but not change the locale.

next-translate docs have an example that mentions rewriting the request adding a lang search param using a middleware. But is this really the recommended way to solve this? It feels like rewriting requests to add fake i18n stuff is a hack and shouldn't be necessary, considering locale in our app has nothing to do with paths.

I mean, can't we just read the cookie and set the locale without any of that? I'm not sure how exactly it is done right now, but having some sort of centralized way to set the locale for the current page during server rendering would be great. I see that next-translate has its own cookie to store the user preference (does it work with the app directory?), but I need the locale to be correct right away, on the first load (some deployments of the app have a fixed locale).

Just want to hear your perspective, if I'm maybe overlooking some feature of next-translate or you see some way to implement this behavior.

[vktrl]

Trying to solve the same problem myself. Migrating from a SPA and route-based approach is a no-no.

Server side seems to be pretty straightforward, just try to get locale from a cookie, then headers or fall back to default. The big question is how to create some sort of a shared context as a single source of truth between the server and client components. Looking at Jotai as a potential solution right now.

[Curetix]

Hi @vktrl, I'm just wondering if you had found any approach to this issue? I'm planning the migration to the app directory, and the translations are my biggest concern. The "offical" example with a query parameter or a dynamic [lang] routing segment at the root level just seem so clunky.

[J4v4Scr1pt]

+1 on this!
I can't belive that there are no i18n packages out there that handle this. I can't imagen that all applications out there on www are using route based culture.

[Curetix]

I ended up switching to next-i18next and building custom language detection using cookies, query params, and headers. This solution is also not perfect, since it relies on server side props and therefore opts out of any static site generation, but that's fine for my project. Haven't tried using it with the app router yet.

[J4v4Scr1pt]

@Curetix I found another approach below 👇

[J4v4Scr1pt]

For anyone looking in to this, next-translate is truly awesome.
They also support queryParam as lang selector.
Just follow the normal install guide, but skip the add slug part [lang]. Then in the middleware add this:

export default async function middleware(request: NextRequest) {
	const locale = request.nextUrl.locale || i18n.defaultLocale; // Here you could use another saved user setting for locale
	request.nextUrl.searchParams.set('lang', locale);
	request.nextUrl.href = request.nextUrl.href.replace(`/${locale}`, '');
	return NextResponse.rewrite(request.nextUrl);
}

Thats it!

(Using App-folder)

Edit:
Jumped to early, there are still issues... 😞