next-translate icon indicating copy to clipboard operation
next-translate copied to clipboard

Dynamic routes using the wrong locale in Next 13.4.13

Open Curetix opened this issue 1 year ago • 2 comments

What version of this package are you using? 2.5.3

What operating system, Node.js, and npm version? Windows, Node 20, pnpm

What happened?

I have an app with the two locales en (base) and de. Some of my routes are dynamic, like /[channel] and /video/[id].

After updating to Next 13.4.13, I am encountering this behavior in my app: When navigating to a dynamic route like /[channel], it switches to the base locale even though the URL locale doesn't change. So it would navigate from /de to /de/test, but loads the en locale. When navigating back to a non-dynamic route it uses the correct locale again. This only happens with Next 13.4.13, dynamic routes and when navigating using a router Link or router.push.

Here's the dev server logs:

next-translate - compiled page: / - locale: de - namespaces: common, navbar, home, channel - used loader: getServerSideProps
next-translate - compiled page: /[channelName] - locale: en - namespaces: common, navbar - used loader: getServerSideProps

Curetix avatar Aug 12 '23 09:08 Curetix

I experience something similar while using pages directory.

When navigating through <Link> to a dynamic route or page with getServerSideProps, translations are not loaded. Instead, it shows translation keys i.e. about_us.some.key. After page refresh or when the page opened directly translations show OK. Navigation between static pages works OK.

next-translate and the plugin of v2.5.3, next.js v13.4.13

  • Downgrading next to 13.3.x did not help
  • legacyBehavior on <Link> did not help

Any idea?

========

Update

I figured this is related to middleware.ts. Middleware I use:

export function middleware(req: NextRequest) {
  if (!PUBLIC_FILE.test(req.nextUrl.pathname)) {
    const { browser } = userAgent(req);
    
    if (!isBrowserSupported(browser?.name, browser?.version)) {
      const redirectUrl = req.nextUrl.clone();
      redirectUrl.pathname = '/unsupported.html';

      return NextResponse.redirect(redirectUrl);
    }
  }
}

As you can see, the middleware has nothing to do with locale.

If I delete middleware.ts, navigation works as expected and all translations are loaded.

@aralroca I saw a workaround with [lang] prefix but in my case:

  1. there is only one locale. In i18.js I have locales: ['en']
  2. only pages directory is in use. app directory is not even created
  3. locale is not visible in the url. All urls are in format site.com/about rather than site.com/en/about or site.com/about?lang=en

Is it a known problem? I do not want to remove the middleware, and want to keep urls in current format site.com/about

shelooks16 avatar Aug 14 '23 13:08 shelooks16

I can confirm what @shelooks16 has found. When removing my middleware.ts, which does not handle anything locale-related, this issues does not occur.

Curetix avatar Aug 15 '23 09:08 Curetix