Next.js localization for the App Router and Pages Router

Sub-path routing gives every language a visible URL, such as /en/pricing and /fr/pricing. It works on one domain, is easy to test, and makes language switching a path transformation. Domain routing, such as example.fr, can support market-specific branding or legal requirements, but adds DNS, deployment, analytics, and canonicalization work. Choose domains for product reasons, not because localization requires them.

In the App Router, put all localized pages under app/[locale]. A Proxy can inspect the pathname, cookie, or Accept-Language header at request time and redirect a neutral entry URL to a locale. Next.js 16 renamed middleware.ts to proxy.ts, although older applications still use the middleware name. Treat negotiation as a convenience: every localized URL must remain directly accessible and the switcher should use ordinary crawlable links.

A pure static export cannot execute Proxy, read request cookies, or perform request-time redirects. For output: 'export', enumerate locale segments with generateStaticParams and provide a static entry experience, such as a default-locale homepage or a visible language chooser. Do not promise automatic browser-language detection in an environment that has no request runtime.

The Pages Router's next.config.js i18n option supports locale sub-paths and domains in deployed Next.js applications. It is not compatible with output: 'export'. If a Pages Router project must produce only static files, model locale as an explicit dynamic segment and generate those routes rather than enabling the built-in i18n field. Static generation and static export are related, but they are not the same deployment mode.

app/
  [locale]/
    layout.tsx
    page.tsx
    pricing/
      page.tsx
messages/
  en.json
  fr.json
  de.json

The following sequence uses an App Router application because it exposes the decisions most new projects face. The exact imports vary by library, but the boundaries remain stable: validate locale at the route, load server messages for that request, provide only what Client Components need, and generate known locales during the build when the page can be static.

1. Step 1

   Add the locale route segment

   Create app/[locale] and move localized layouts and pages beneath it. Validate params against one supported-locale list and return not found for unknown values.

2. Step 2

   Define negotiation and fallback

   Decide what happens at a URL without a locale. A request runtime can negotiate and redirect; a static export needs a deterministic default page or language chooser. Always preserve direct access to locale URLs.

3. Step 3

   Create scoped message catalogs

   Organize messages by product area or route rather than placing the whole application in one file. Keep the same namespace shape across locales, validate missing keys in CI, and avoid importing all languages into a Client Component.

4. Step 4

   Load messages on the server

   Resolve one validated catalog for each request or generated route. Keep server instances request-scoped when the library stores active-locale state, preventing concurrent requests from leaking language choices.

5. Step 5

   Separate server and client translation

   Translate in Server Components by default. Add a provider or client hook only across the smallest interactive boundary that needs it, and pass translated labels as props when that is simpler.

6. Step 6

   Generate locale variants

   Return every supported locale from generateStaticParams for static pages. Dynamic content may also need slug-and-locale combinations. Rebuild whenever catalogs or the locale list changes.

import {NextIntlClientProvider} from 'next-intl';
import {getMessages} from 'next-intl/server';

export default async function LocaleLayout({children, params}: Props) {
  const {locale} = await params;
  const messages = await getMessages();

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

const locales = ['en', 'fr', 'de'] as const;

export function generateStaticParams() {
  return locales.map((locale) => ({locale}));
}

Keep the root locale layout responsible for language-wide concerns: validating params, loading the catalog, setting html lang and dir, and establishing any client provider. Pages should request messages by namespace and avoid knowing where catalogs live. That separation makes it possible to replace local JSON imports with a build-time download or CDN-backed workflow without rewriting every component.

For the Pages Router, translate the same responsibilities into next.config.js locale routing, getStaticProps or getServerSideProps message loading, and getStaticPaths for dynamic localized pages. The router APIs differ, but the catalog and component layers can remain consistent. During a migration, support both routers deliberately and verify that navigation never drops the locale prefix.

Rendered HTML is only the start of multilingual SEO. Search engines need a distinct, stable URL for each language version and clear links among alternatives. In the App Router, generateMetadata can produce localized titles and descriptions plus alternates.canonical and alternates.languages. A sitemap can also list language alternates. Use one consistent URL policy so metadata, navigation, and sitemap entries never disagree.

Each localized page should reference itself and every equivalent locale with reciprocal hreflang annotations. Use absolute URLs in production and add x-default when a neutral selector or default experience is useful. A canonical usually points to the current language version, not automatically to English. When a page is unavailable in a locale, omit that unsupported alternative rather than sending crawlers to unrelated content.

Do not depend on Accept-Language alone. Googlebot commonly crawls without a useful language preference, and locale-adaptive content at one URL can hide variants. Keep locale pages reachable through normal anchors. Set html lang for browsers and assistive technology, but remember that Google determines language mainly from visible content, so the translation itself must be substantial and coherent.

• ✓ Return complete localized HTML at a stable, crawlable URL.
• ✓ Localize the title, description, headings, and visible body—not only the navigation shell.
• ✓ Emit a canonical for the current page and reciprocal hreflang links for every available locale.
• ✓ Include localized URLs in the sitemap and use x-default for a neutral fallback when appropriate.
• ✓ Keep a crawlable language switcher and avoid forced redirects that trap users or bots in one locale.

A Next.js library decides how the application selects and renders messages. A localization platform addresses the surrounding lifecycle: collecting keys, translating values, reviewing changes, keeping locale catalogs aligned, and delivering approved content. Those concerns become visible as soon as copy changes more often than deployments or contributors extend beyond one developer.

Translatable is built around JSON localization files. Teams can import existing catalogs, edit or translate them with AI assistance, synchronize through Git providers, and distribute updates through a CDN. The application keeps ownership of its routing and i18n library, so message delivery can evolve without tying view components to a proprietary runtime.

Start with checked-in catalogs and a build-time workflow. Introduce remote delivery only where faster copy updates create real value, and preserve a bundled fallback for critical pages. This progressive path keeps static rendering deterministic while giving content teams a cleaner route to production when the product grows.