Next.js-Lokalisierung für App Router und Pages Router

Unterpfad-Routing gibt jeder Sprache eine sichtbare URL wie /en/pricing und /fr/pricing. Es funktioniert auf einer einzigen Domain, lässt sich einfach testen und macht den Sprachwechsel zu einer Pfadtransformation. Domain-Routing wie example.fr kann marktspezifisches Branding oder rechtliche Anforderungen unterstützen, verursacht aber zusätzlichen Aufwand für DNS, Bereitstellung, Analysen und Kanonisierung. Wählen Sie Domains aus Produktgründen und nicht, weil die Lokalisierung sie erfordert.

Legen Sie im App Router alle lokalisierten Seiten unter app/[locale] ab. Ein Proxy kann den Pfadnamen, ein Cookie oder den Accept-Language-Header zur Anfragezeit prüfen und eine neutrale Einstiegs-URL zu einer Sprache weiterleiten. Next.js 16 hat middleware.ts in proxy.ts umbenannt, ältere Anwendungen verwenden jedoch weiterhin den Namen middleware. Betrachten Sie die Erkennung als Komfortfunktion: Jede lokalisierte URL muss direkt erreichbar bleiben, und die Sprachauswahl sollte gewöhnliche crawlbare Links verwenden.

Ein rein statischer Export kann keinen Proxy ausführen, keine Anfrage-Cookies lesen und keine Weiterleitungen zur Anfragezeit vornehmen. Zählen Sie für output: 'export' die Sprachsegmente mit generateStaticParams auf und stellen Sie einen statischen Einstieg bereit, etwa eine Startseite in der Standardsprache oder eine sichtbare Sprachauswahl. Versprechen Sie keine automatische Erkennung der Browsersprache in einer Umgebung ohne Anfrage-Laufzeit.

Die i18n-Option in next.config.js des Pages Routers unterstützt in bereitgestellten Next.js-Anwendungen sprachspezifische Unterpfade und Domains. Sie ist nicht mit output: 'export' kompatibel. Wenn ein Pages-Router-Projekt ausschließlich statische Dateien erzeugen muss, modellieren Sie die Sprache als explizites dynamisches Segment und generieren Sie diese Routen, statt das integrierte i18n-Feld zu aktivieren. Statische Generierung und statischer Export hängen zusammen, sind aber nicht derselbe Bereitstellungsmodus.

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

Die folgende Abfolge verwendet eine App-Router-Anwendung, da sie die Entscheidungen sichtbar macht, vor denen die meisten neuen Projekte stehen. Die genauen Importe unterscheiden sich je nach Bibliothek, doch die Grenzen bleiben gleich: Validieren Sie die Sprache an der Route, laden Sie Servernachrichten für diese Anfrage, stellen Sie nur das bereit, was Client Components benötigen, und generieren Sie bekannte Sprachen während des Builds, wenn die Seite statisch sein kann.

1. Schritt 1

   Das sprachspezifische Routensegment hinzufügen

   Erstellen Sie app/[locale] und verschieben Sie lokalisierte Layouts und Seiten darunter. Validieren Sie Parameter anhand einer einzigen Liste unterstützter Sprachen und geben Sie für unbekannte Werte eine Nicht-gefunden-Antwort zurück.

2. Schritt 2

   Spracherkennung und Fallback definieren

   Legen Sie fest, was bei einer URL ohne Sprache geschieht. Eine Anfrage-Laufzeit kann die Sprache aushandeln und weiterleiten; ein statischer Export benötigt eine deterministische Standardseite oder Sprachauswahl. Bewahren Sie stets den direkten Zugriff auf sprachspezifische URLs.

3. Schritt 3

   Abgegrenzte Nachrichtenkataloge erstellen

   Ordnen Sie Nachrichten nach Produktbereich oder Route, statt die gesamte Anwendung in einer Datei abzulegen. Behalten Sie in allen Sprachen dieselbe Namespace-Struktur bei, validieren Sie fehlende Schlüssel in CI und vermeiden Sie es, alle Sprachen in eine Client Component zu importieren.

4. Schritt 4

   Nachrichten auf dem Server laden

   Ermitteln Sie für jede Anfrage oder generierte Route genau einen validierten Katalog. Halten Sie Serverinstanzen anfragegebunden, wenn die Bibliothek den Status der aktiven Sprache speichert, damit parallele Anfragen keine Sprachauswahl untereinander übertragen.

5. Schritt 5

   Server- und Client-Übersetzung trennen

   Übersetzen Sie standardmäßig in Server Components. Fügen Sie einen Provider oder Client-Hook nur über die kleinstmögliche interaktive Grenze hinzu, die ihn benötigt, und übergeben Sie übersetzte Beschriftungen als Props, wenn dies einfacher ist.

6. Schritt 6

   Sprachvarianten generieren

   Geben Sie aus generateStaticParams für statische Seiten jede unterstützte Sprache zurück. Dynamische Inhalte benötigen möglicherweise zusätzlich Kombinationen aus Slug und Sprache. Führen Sie einen erneuten Build aus, wenn sich Kataloge oder die Sprachenliste ändern.

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}));
}

Das oberste Sprachlayout sollte für sprachübergreifende Belange verantwortlich sein: Parameter validieren, den Katalog laden, html lang und dir setzen und gegebenenfalls einen Client-Provider einrichten. Seiten sollten Nachrichten nach Namespace anfordern und nicht wissen müssen, wo Kataloge gespeichert sind. Diese Trennung ermöglicht es, lokale JSON-Importe durch einen Download zur Build-Zeit oder einen CDN-gestützten Workflow zu ersetzen, ohne jede Komponente umzuschreiben.

Übertragen Sie beim Pages Router dieselben Verantwortlichkeiten auf das sprachspezifische Routing in next.config.js, das Laden von Nachrichten mit getStaticProps oder getServerSideProps und getStaticPaths für dynamische lokalisierte Seiten. Die Router-APIs unterscheiden sich, Katalog- und Komponentenebenen können jedoch einheitlich bleiben. Unterstützen Sie während einer Migration beide Router bewusst und prüfen Sie, dass die Navigation das Sprachpräfix nie verliert.

Gerendertes HTML ist nur der Anfang mehrsprachiger SEO. Suchmaschinen benötigen für jede Sprachversion eine eindeutige, stabile URL und klare Verknüpfungen zwischen den Alternativen. Im App Router kann generateMetadata lokalisierte Titel und Beschreibungen sowie alternates.canonical und alternates.languages erzeugen. Eine Sitemap kann ebenfalls Sprachalternativen aufführen. Verwenden Sie eine einheitliche URL-Richtlinie, damit Metadaten, Navigation und Sitemap-Einträge nie voneinander abweichen.

Jede lokalisierte Seite sollte mit wechselseitigen hreflang-Annotationen auf sich selbst und jede gleichwertige Sprachvariante verweisen. Verwenden Sie in der Produktion absolute URLs und fügen Sie x-default hinzu, wenn eine neutrale Auswahl oder Standardansicht sinnvoll ist. Die kanonische URL verweist normalerweise auf die aktuelle Sprachversion und nicht automatisch auf Englisch. Wenn eine Seite in einer Sprache nicht verfügbar ist, lassen Sie diese nicht unterstützte Alternative weg, statt Crawler zu nicht verwandten Inhalten zu führen.

Verlassen Sie sich nicht allein auf Accept-Language. Googlebot crawlt häufig ohne brauchbare Sprachpräferenz, und sprachadaptiver Inhalt unter einer einzigen URL kann Varianten verbergen. Halten Sie Sprachseiten über normale Links erreichbar. Setzen Sie html lang für Browser und Hilfstechnologien, beachten Sie jedoch, dass Google die Sprache hauptsächlich anhand sichtbarer Inhalte bestimmt. Die Übersetzung selbst muss daher substanziell und stimmig sein.

• ✓ Geben Sie vollständiges lokalisiertes HTML unter einer stabilen, crawlbaren URL zurück.
• ✓ Lokalisieren Sie Titel, Beschreibung, Überschriften und sichtbaren Inhalt – nicht nur die Navigationshülle.
• ✓ Geben Sie eine kanonische URL für die aktuelle Seite und wechselseitige hreflang-Links für jede verfügbare Sprache aus.
• ✓ Nehmen Sie lokalisierte URLs in die Sitemap auf und verwenden Sie gegebenenfalls x-default für einen neutralen Fallback.
• ✓ Behalten Sie eine crawlbare Sprachauswahl bei und vermeiden Sie erzwungene Weiterleitungen, die Nutzer oder Bots in einer Sprache festhalten.

Eine Next.js-Bibliothek bestimmt, wie die Anwendung Nachrichten auswählt und rendert. Eine Lokalisierungsplattform kümmert sich um den begleitenden Lebenszyklus: Schlüssel erfassen, Werte übersetzen, Änderungen prüfen, Sprachkataloge abgleichen und freigegebene Inhalte bereitstellen. Diese Anforderungen werden sichtbar, sobald sich Texte häufiger als Bereitstellungen ändern oder neben einem einzelnen Entwickler weitere Mitwirkende hinzukommen.

Translatable basiert auf JSON-Lokalisierungsdateien. Teams können vorhandene Kataloge importieren, sie mit KI-Unterstützung bearbeiten oder übersetzen, über Git-Anbieter synchronisieren und Aktualisierungen über ein CDN verteilen. Die Anwendung behält die Kontrolle über Routing und i18n-Bibliothek, sodass sich die Nachrichtenbereitstellung weiterentwickeln kann, ohne View-Komponenten an eine proprietäre Laufzeit zu binden.

Beginnen Sie mit eingecheckten Katalogen und einem Workflow zur Build-Zeit. Führen Sie die Remote-Bereitstellung nur dort ein, wo schnellere Textaktualisierungen echten Mehrwert schaffen, und bewahren Sie für kritische Seiten einen gebündelten Fallback. Dieser schrittweise Ansatz hält statisches Rendering deterministisch und bietet Content-Teams zugleich einen einfacheren Weg in die Produktion, wenn das Produkt wächst.