Open iljamulders opened 10 months ago
Anyone have solved it? I am also struggling with it.
Think it's the same as #53724
next: 14.0.4
the problem is relevant
with the logical next.config.ts.
/ - page is displayed
/nl - 404
/en - 404
Hi, another dev trying to use app router in existing internationalized next app with pages router.
I also confirm this is still a problem in 14.0.4
as I tested it using reproduction repo https://github.com/iljamulders/nextjs-i18n-incremental-adopt, thanks @iljamulders.
It seems that any locale you specify in next.config i18n.locales
make subsequent path segments to be routed only to pages router and ignores any routes in app router.
Only workaround I see is to put app router routes under extra path e.g. /extra/nl/about
which wouldn't match the i18n logic in pages router. That's not desirable as you can't move existing pages under app router without changing urls.
I've experienced this first in https://nextjs.org/blog/next-13-4 only on Vercel production (not locally) of our existing app, but couldn't reproduce locally and not even on Vercel deployment with a new Next.js project. Currently it behaves same during development and in production.
@leerob Hi, there seems to be i18n incompatibility using app and pages router together since day one. There is very clear and simple reproduction repository. Could you have a look?
@simonmares & @leerob Unfortunately we still can't use the new app router after more than a year of it being stable :(
@leerob could you shed any light on when this issue will be addressed? PS love your youtube vids, keep them coming!
How about using monorepo with pages router and app router? If I use monorepo and create next configuration file for each project, I think it should be work.
This is blocking us too. All routes are internationalised, and migrating ~30 complex pages at the same time in a high traffic repo makes this a no-go for now.
I would expect the behaviour of trying to match any route in the app router first before looking at the config locales and matching them against the pages router. That seems to be what's going on here, but maybe i'm looking in the wrong place: https://github.com/vercel/next.js/blob/f45a15b621225a4ad3d401e4d3d114dd17647a90/packages/next/src/server/require.ts#L24
Hey folks, sorry for the slow reply here. You are correct there isn't a way to mix the Pages Router i18n
configuration with the App Router. This does make incremental adoption more difficult in this case. One option is to move the Pages Router setup from the i18n
configuration to a Middleware-based configuration. Since this is the approach recommended in the App Router, it would allow you to then incrementally move routes from Pages -> App as you're ready. Hope this helps.
@leerob
Thanks for your reply! I will give this a go.
Some notes for other devs trying to achieve this:
If you remove the i18n config, the lang attribute will be removed from <html>
, so remember to add it as high as possible in your pages/_app.tsx
Next.js renders the closest not-found page when a route segment calls the notFound function. We can use this mechanism to provide a localized 404 page by adding a not-found file within the [locale] folder.
// app/[locale]/not-found.tsx
// not-found.js components do not accept any props.
// So we need to make it a client component and useParams() to get the locale
'use client'
import { useParams } from 'next/navigation'
export default function NotFoundPage() {
const params = useParams()
return <h1>404 with locale: {params?.locale}</h1>
}
Note however that Next.js will only render this page when the notFound function is called from within a route, not for all unknown routes in general.
To catch unknown routes too, you can define a catch-all route that explicitly calls the notFound function.
// app/[locale]/[...rest]/page.tsx
import {notFound} from 'next/navigation';
export default function CatchAllPage() {
notFound();
}
@leerob could you please elaborate on this? If I understand it correctly, translation libraries, such as next-translate, were depending on built-in i18n
property and the routing features it gives. Now, in app dir i18n is handled by the developers themselves, yet the presence of i18n
key on next.config.js
affecting routing for both pages and app dir. So I can't quite comprehend how the use of middleware would help us here? Shouldn't this be marked as a critical bug and prioritized then? It looks like partial migration from pages to app dir is currently not possible entirely and the only choice we have at this point is to start developing new application using only app dir and somehow connect pages and app applications through DNS and redirects which doubles the effort and hosting expenses.
Link to the code that reproduces this issue
https://github.com/iljamulders/nextjs-i18n-incremental-adopt
To Reproduce
Current vs. Expected behavior
The internationalization example will always return a
404 not found
when i18n is turned on in next.config.jsThis makes it impossible to incrementally adopt to the app router.
Expected behavior
https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#migrating-from-pages-to-app
Verify canary release
Provide environment information
Which area(s) are affected? (Select all that apply)
App Router, Internationalization (i18n)
Additional context
No response