Serving the right language and locale-specific content, based on the URL.
The App Router removed the built-in i18n routing configuration the Pages Router used to have, so internationalization is now implemented as a routing pattern you build yourself — typically a [locale] dynamic segment at the top of the route tree, with Middleware detecting the user's preferred locale (from the Accept-Language header or a stored cookie) and redirecting or rewriting to the correctly locale-prefixed path.
This is usually paired with a library like next-intl, or a custom dictionary-loading setup, to actually manage translated strings per locale — and with generateStaticParams to pre-render every supported locale's version of a static page at build time, rather than translating on the fly for every request. The routing logic and the translation-content management are genuinely two separate concerns, and keeping them that way makes both easier to reason about independently.
What you'll walk away knowing