App directory [lang] paths return 404 from NextJS v13.4.13

[nickderobertis-ch]

What version of this package are you using?

v2.5.3

What operating system, Node.js, and npm version?

MacOS, v18.7.0, 8.15.0

What happened?

Navigating to app directory pages with the [lang] path parameter returns 404 when NextJS is upgraded to 13.4.13 or later.

I have created a simple reproduction of the issue in this repo. I simply used the NextJS official example for next-translate. When I first started it up it was working, but then once I upgraded NextJS and restarted the server, it started getting 404. I tried different versions of NextJS until I found that v13.4.12 works but v13.4.13 and later do not.

What did you expect to happen?

Page loads successfully.

Are you willing to submit a pull request to fix this bug?

I am motivated to get this fixed quickly, so I would be willing to help but I am not familiar with the internals of next-translate or next. With some guidance I would be happy to do the heavy lifting.

There are quite a lot of changes from 13.4.12 to 13.4.13, so it's not immediately clear why this broke.

[nickderobertis-ch]

There were a couple changes around basePath, maybe that's a good place to look.

• https://github.com/vercel/next.js/pull/53174
• https://github.com/vercel/next.js/pull/53189

[abuu-u]

next.config.js

setting i18n to undefined worked for me, idk if this has any drawbacks

const nextTranslate = require("next-translate-plugin");
const config = nextTranslate({});
config.i18n = undefined;

module.exports = config;

[oscarrc]

next.config.js

setting i18n to undefined worked for me, idk if this has any drawbacks

const nextTranslate = require("next-translate-plugin");
const config = nextTranslate({});
config.i18n = undefined;

module.exports = config;

I can confirm this removes the issue, it also helps with https://github.com/aralroca/next-translate/issues/1141 (more info there), but, as you've said, I don't know what the drawbacks could be, if any.

I guess, since i18n support has been dropped for the App router, that config section doesn´t make sense when using said router (no mention to it in the App route docs for internationalization).

[nickderobertis-ch]

setting i18n to undefined worked for me, idk if this has any drawbacks

Nice find, this seems like a good workaround if only app directory is used. The i18n attribute is still used for the pages directory. In our case, we have an existing application on pages and are trying to migrate it to app directory incrementally, so we need it working in both.

[oscarrc]

The problem is Next.js normalizes nextUrl.pathname by removing the locale when i18n config is present. But you're right, the config needs to be present in the case of incremental migration, so I think this is something that needs to be solved in their end.

[nickderobertis-ch]

I actually found a bug on the NextJS side that may be the cause of this: https://github.com/vercel/next.js/issues/53724

[deifos]

Setting i18n to undefined solved my problem but now I see that the locale in the request.nextUrl is removed by nextJS, any work arounds for this?

[bruno-gurgel]

Same here. Setting i18n to undefined fixes the issue but I would love a more permanent and less hacky solution

[aralroca]

The i18n is there to support migration from pages to app, i18n is required for pages, but not for app. Feel free for now to remove it. Probably we are going to drop the support for the migration from pages to app BECAUSE NEXT.JS is not supporting this migration, there are a lot of issues to have the i18n in app router, when this i18n should be used only in pages without interfering to app router... :/

[Zagorakiss]

Hi everyone. config.i18n = undefined; solved the issue.

But now i'm getting errors during production build while nextjs is generating static pages:

Error occurred prerendering page "/500".
RangeError: Incorrect locale information provided

Error occurred prerendering page "/404".
RangeError: Incorrect locale information provided

Export encountered errors on following paths:
        /_error: /404
        /_error: /500

I tried to bring back i18n to next config (removed line config.i18n = undefined;) -> got previous issue but next build completed without errors.

I'm not using pages folder so would like to continue using config.i18n = undefined; because it makes application behaviour more predictable. For more context: i don't have custom error pages. Errors occurred in default nextjs error pages.

[Zagorakiss]

Hi everyone. config.i18n = undefined; solved the issue.

But now i'm getting errors during production build while nextjs is generating static pages:

Error occurred prerendering page "/500".
RangeError: Incorrect locale information provided

Error occurred prerendering page "/404".
RangeError: Incorrect locale information provided

Export encountered errors on following paths:
        /_error: /404
        /_error: /500

I tried to bring back i18n to next config (removed line config.i18n = undefined;) -> got previous issue but next build completed without errors.

I'm not using pages folder so would like to continue using config.i18n = undefined; because it makes application behaviour more predictable. For more context: i don't have custom error pages. Errors occurred in default nextjs error pages.

ah... checked new release (2.6.2) and it contains this fix. thank you.

[kakxem]

Hi, config.i18n = undefined; solved my issue too.

It was hard to find this fix because I wasn't aware that the error started with version 13.4.13. (I upgraded from 13.4.12 to 14.0.0)

Should we update the README with this fix or wait for a better one?

Thanks!

[vonsa]

I'm using pages router and I have a redirect issue on the newer next.js version.

I use this as a temporary solution:

const config = nextTranslate(nextConfig);
config.i18n.localeDetection = false;

module.exports = config;

If it also works for you, it's atleast better than setting i18n to undefined I guess?

[aralroca]

Can you tried in 3.0.0-canary.1 version? (both, next-translate & next-translate-plugin). Thanks

[federicogomezlara]

One thing that wasn't noted, or maybe it's just me, @abuu-u's solution causes fast refresh to break, I am forced to disable translations while developing if I want fast refresh to work