About tradeoff between 2.3.0 and 2.4.x

[hydRAnger]

Our current application is based on Next.js 13.4 (app directory), I found next-translate&next-translate-plugin is the best choice(thanks for your brilliant article), with next-translate 2.3.0, it works very well and helps us a lot. But as 2.3.x seems to have some issues with client components(like this, and this).

So I tried to migrate to next-translate 2.4.x, and the client component issues are solved perfectly. But a new issue is triggered: for some historical reason, besides Next.js's current solution based on the path, our application is required to define the lang with search params(e.g. https://xxx.com?lang=ja), but that didn't work as expected(just like what 2.3.0 did), seems the lang in search params is not detected correctly (I'm not very sure about if it caused by next-translate or next-translate-plugin, sorry).

I'd like to get your advice(or if the lang params detection will recover in the future?)

btw, I used current middleware:

export function middleware(request: NextRequest): NextResponse {
  const locale = request.nextUrl.searchParams.get('lang');

  if (locale && i18n.locales.includes(locale)) {
    return NextResponse.next();
  }

  request.nextUrl.searchParams.set('lang', i18n.defaultLocale);
  return NextResponse.redirect(request.nextUrl);
}

[aralroca]

@hydRAnger I need to update this article. The problem is an issue from Next.js core, the middleware with i18n stops working after Next.js 13.2.5-canary.8.

we are keeping the detection through the lang parameter, but because of this issue the middleware is not working properly. As a solution, we propose to use a dynamic route /[lang].

We updated the docs, the example and also we explained in the release. Please take a look and I hope this works for you meanwhile is not solved in the Next.js core. I'm going to close the issue because is out of the scope of this library, feel free to comment on the Next.js issue.