i18n im Next.js App Router einrichten — Der vollständige Leitfaden 2026

Wenn Sie eine Next.js-Anwendung entwickeln, die mehrere Sprachen unterstützen muss, sind Sie wahrscheinlich schon auf ein Durcheinander aus Konfigurationsdateien, kaputten Middleware-Ketten und Übersetzungen gestoßen, die sich in Server Components weigern zu laden. Dieser Leitfaden führt Sie Schritt für Schritt durch die Einrichtung von Internationalization (i18n) im Next.js 15 App Router mit @better-i18n/next — von null auf produktionsbereit in unter 30 Minuten.

Warum i18n im Next.js App Router anders ist

Wenn Sie i18n mit dem Pages Router verwendet haben, vergessen Sie das meiste, was Sie wissen. Der App Router hat das Spiel verändert:

• Server Components sind der Standard. Sie können React-Hooks wie useTranslations nicht darin verwenden — Sie benötigen getTranslations vom Server.
• Middleware übernimmt jetzt die Locale-Erkennung und das Routing anstelle der i18n-Konfiguration in next.config.js (die in Next.js 13+ entfernt wurde).
• ISR (Incremental Static Regeneration) ermöglicht es, Übersetzungen am Edge zu cachen und im Hintergrund neu zu validieren — kein vollständiger Rebuild bei Übersetzungsänderungen.
• Streaming bedeutet, dass Ihr Layout sofort gerendert werden kann, während Übersetzungen asynchron geladen werden.

Die meisten i18n-Bibliotheken hatten Schwierigkeiten, sich anzupassen. @better-i18n/next wurde speziell für diese Architektur entwickelt und liefert Übersetzungen über ein globales CDN mit ISR-Caching und einer kompositionsfähigen Middleware-API.

Warum i18n wichtig ist

Über 60 % der Internetnutzer bevorzugen es, in ihrer Muttersprache zu surfen. Für SaaS-Produkte, E-Commerce-Shops und Content-Plattformen, die mit Next.js entwickelt werden, ist Lokalisierung kein Nice-to-have — sie ist ein Wachstumsmultiplikator. Richtig implementiertes i18n verbessert:

• SEO-Rankings in nicht-englischsprachigen Märkten durch hreflang-Tags und lokalisierte URLs. Eine solide localization SEO strategy multipliziert den Wert jeder übersetzten Seite.
• Konversionsraten um über 70 %, wenn Nutzer Inhalte in ihrer Sprache sehen
• Nutzerbindung durch ein nativ wirkendes Erlebnis

Die Verschiebung hin zu entwicklerorientierten Tools hat i18n auch schneller adoptierbar gemacht. Why developer-first localization wins in 2026 erklärt die breiteren Kräfte, die Teams von übersetzerzentrischen Workflows hin zu code-nativen Setups wie dem hier aufgebauten treiben.

Wenn Sie einen mobilen Hintergrund haben, beachten Sie, dass sich die Muster hier von React Native Expo localization unterscheiden — App Router verwendet serverseitiges Nachrichten-Laden und ISR-Caching anstelle von gebündelten Locale-Dateien, was ein bedeutender architektonischer Unterschied ist. Für eine breitere Einführung in die Terminologie der Internationalisierung vor dem Einstieg in den Code ist localization and internationalisation fundamentals eine nützliche Einführung.

Was Sie aufbauen werden

Am Ende dieses Leitfadens wird Ihre Next.js-App Folgendes haben:

1. Automatische Locale-Erkennung aus URL, Cookies und Browser-Headern
2. Serverseitiges Übersetzungsladen mit ISR-Caching
3. Clientseitiges sofortiges Locale-Wechseln ohne Seitenneuladen
4. SEO-optimiertes Routing mit hreflang und kanonischen URLs
5. Typsichere Übersetzungen mit Namespace-Scoping

1. Installation

Beginnen Sie mit der Installation von @better-i18n/next und seinen Peer-Abhängigkeiten:

npm install @better-i18n/next next-intl

@better-i18n/next benötigt Next.js 15+ und next-intl 4+ als Peer-Abhängigkeiten. Es baut auf next-intls bewährter Anforderungsverarbeitung auf und fügt CDN-gestützte Übersetzungslieferung, automatische Locale-Erkennung und eine kompositionsfähige Middleware-API hinzu.

2. Ihre i18n-Konfiguration erstellen

Erstellen Sie eine zentrale Konfigurationsdatei, auf die der Rest Ihrer App verweist. Dies ist die einzige Wahrheitsquelle für Ihr i18n-Setup.

// i18n/config.ts
import { createI18n } from "@better-i18n/next";

export const i18n = createI18n({
  project: "acme/dashboard",       // Ihr Better i18n-Projektbezeichner
  defaultLocale: "en",             // Fallback-Locale
  localePrefix: "as-needed",       // URL-Strategie (siehe Abschnitt 6)
  timeZone: "UTC",                 // Einheitliche Datums-/Zeitformatierung
});

Die createI18n-Funktion gibt ein Objekt mit allem zurück, was Sie benötigen:

Konfigurationsoptionen

Das I18nConfig-Interface erweitert die Kernkonfiguration um Next.js-spezifische Optionen:

interface I18nConfig {
  project: string;                    // "org/project"-Format
  defaultLocale: string;              // z.B. "en"
  localePrefix?: "as-needed" | "always" | "never";
  cookieName?: string;                // Standard: "locale"
  manifestRevalidateSeconds?: number; // ISR für Manifest (Standard: 3600)
  messagesRevalidateSeconds?: number; // ISR für Übersetzungen (Standard: 30)
  timeZone?: string;                  // IANA-Zeitzonenbezeichner
  storage?: TranslationStorage;       // Offline-Fallback-Speicher
  staticData?: Record<string, Messages>; // Gebündelte Fallback-Übersetzungen
  fetchTimeout?: number;              // CDN-Timeout in ms (Standard: 10000)
  retryCount?: number;                // Wiederholungsversuche (Standard: 1)
}

3. Die Middleware konfigurieren

Die Middleware verwaltet die Locale-Erkennung und das URL-Routing. Sie läuft bei jeder Anfrage, erkennt die bevorzugte Sprache des Nutzers und stellt sicher, dass die URL-Struktur Ihrer Locale-Prefix-Strategie entspricht.

Einfaches Setup

Für die meisten Apps reicht eine einzige Zeile:

// middleware.ts
import { i18n } from "./i18n/config";

export default i18n.betterMiddleware();

export const config = {
  matcher: ["/((?!api|_next|.*\\..*).*)`"],
};

Mit Authentifizierung (Clerk-Style-Callback)

Wenn Sie i18n mit Authentifizierung kombinieren müssen, akzeptiert betterMiddleware einen Callback, der Ihnen Zugriff auf die erkannte Locale und die i18n-Antwort gibt:

// middleware.ts
import { NextResponse } from "next/server";
import { i18n } from "./i18n/config";

export default i18n.betterMiddleware(async (request, { locale, response }) => {
  const isProtected = request.nextUrl.pathname.includes("/dashboard");
  const isLoggedIn = request.cookies.get("session")?.value;

  if (isProtected && !isLoggedIn) {
    return NextResponse.redirect(
      new URL(`/${locale}/login`, request.url)
    );
  }

  // Nichts zurückgeben = die i18n-Antwort wird verwendet (Header bleiben erhalten!)
});

export const config = {
  matcher: ["/((?!api|_next|.*\\..*).*)`"],
};

Dieses Muster ersetzt den veralteten composeMiddleware-Ansatz. Der Callback erhält die vollständig aufgelöste Locale und die Antwort mit bereits gesetzten i18n-Headern, sodass Sie sich auf Ihre Auth-Logik konzentrieren können, ohne sich um Header-Konflikte sorgen zu müssen.

Wie die Locale-Erkennung funktioniert

Die Middleware erkennt die Locale des Nutzers über eine Prioritätskette:

1. URL-Pfad — /fr/about ergibt fr
2. Cookie — Das locale-Cookie (bei vorherigen Besuchen gesetzt)
3. Browser-Header — Der Accept-Language-Header
4. Standard — Fällt auf defaultLocale zurück

Verfügbare Locales werden bei jeder Anfrage vom Better i18n CDN abgerufen (im Speicher gecacht). Wenn eine neue Locale erkannt wird, wird automatisch ein Cookie für zukünftige Besuche gesetzt.

4. Die Request-Konfiguration einrichten

Die Request-Konfiguration teilt next-intl mit, wie Übersetzungen für jede Anfrage geladen werden. Better i18n übernimmt dies durch das Abrufen von Nachrichten vom CDN mit ISR-Caching.

// i18n/request.ts
import { i18n } from "./config";

export default i18n.requestConfig;

Unter der Haube führt requestConfig bei jeder Serveranfrage Folgendes aus:

1. Locale aus dem Middleware-Header auflösen (oder auf Cookie, dann Standard zurückfallen)
2. Übersetzungen vom CDN mit Next.js ISR-Revalidierung abrufen
3. Zeitzone auflösen, um Hydratationsfehlanpassungen zu vermeiden
4. { locale, messages, timeZone } an next-intl zurückgeben

Die ISR-Strategie bedeutet, dass Übersetzungen auf dem Server gecacht und im Hintergrund neu validiert werden — Manifest-Daten werden standardmäßig alle 3600 Sekunden (1 Stunde) und Übersetzungsnachrichten alle 30 Sekunden neu validiert. Sie können dies mit den Konfigurationsoptionen manifestRevalidateSeconds und messagesRevalidateSeconds anpassen.

5. Übersetzungen in Komponenten verwenden

Server Components

Verwenden Sie in Server Components die getTranslations-Funktion von next-intl:

// app/[locale]/page.tsx
import { getTranslations } from "next-intl/server";

export default async function HomePage() {
  const t = await getTranslations("home");

  return (
    <main>
      <h1>{t("title")}</h1>
      <p>{t("description")}</p>
    </main>
  );
}

Client Components

Verwenden Sie in Client Components den useTranslations-Hook:

"use client";

import { useTranslations } from "next-intl";

export function WelcomeBanner() {
  const t = useTranslations("home");

  return (
    <section>
      <h2>{t("welcome")}</h2>
      <p>{t("subtitle", { name: "Developer" })}</p>
    </section>
  );
}

Namespace-Scoping

Übersetzungen sind nach Namespace organisiert. Wenn Sie useTranslations("home") oder getTranslations("home") aufrufen, beschränken Sie sich auf den home-Namespace in Ihren Übersetzungsdateien:

{
  "home": {
    "title": "Willkommen bei Acme",
    "description": "Das beste Dashboard für Ihr Unternehmen",
    "welcome": "Hallo, {name}!",
    "subtitle": "Los geht's"
  },
  "auth": {
    "login": "Anmelden",
    "logout": "Abmelden"
  }
}

Dies verhindert Schlüsselkonflikte in verschiedenen Teilen Ihrer App und hält Übersetzungsdateien wartbar, wenn Ihre App wächst.

6. URL-Locale-Prefix-Strategien

Die Option localePrefix steuert, wie Locales in URLs erscheinen. Wählen Sie die Strategie, die zu Ihrer App passt:

"as-needed" (Standard)

Die Standard-Locale hat kein Prefix. Andere Locales erhalten ein Prefix.

createI18n({ localePrefix: "as-needed", defaultLocale: "en" });

"always"

Jede Locale erhält ein Prefix, einschließlich der Standard-Locale.

createI18n({ localePrefix: "always", defaultLocale: "en" });

"never"

Keine Locale erscheint in der URL. Die Locale wird vollständig durch Cookie und Browser-Header bestimmt.

createI18n({ localePrefix: "never", defaultLocale: "en" });

Bei Verwendung von "never" umgeht die Middleware das URL-Rewriting von next-intl vollständig und setzt die Locale über den x-middleware-request-x-next-intl-locale-Header. Die Request-Konfiguration fällt auf das Lesen des locale-Cookies zurück, wenn der Middleware-Header nicht verfügbar ist.

7. Clientseitiges Locale-Wechseln

Better i18n bietet zwei Ansätze zum Wechseln der Locale auf dem Client, je nachdem, ob Sie sofortiges Wechseln oder einen serveraktualisierenden Ansatz wünschen.

Sofortiges Wechseln mit BetterI18nProvider

Umschließen Sie Ihr Layout mit BetterI18nProvider, um sofortiges Locale-Wechseln ohne Seitenneuladen zu ermöglichen:

// app/[locale]/layout.tsx
import { getLocale, getMessages } from "next-intl/server";
import { BetterI18nProvider } from "@better-i18n/next/client";

export default async function LocaleLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const locale = await getLocale();
  const messages = await getMessages();

  return (
    <html lang={locale}>
      <body>
        <BetterI18nProvider
          locale={locale}
          messages={messages}
          config={{ project: "acme/dashboard", defaultLocale: "en" }}
        >
          {children}
        </BetterI18nProvider>
      </body>
    </html>
  );
}

Verwenden Sie dann den useSetLocale-Hook überall in Ihrem Komponentenbaum:

"use client";

import { useSetLocale } from "@better-i18n/next/client";

export function LanguageSwitcher() {
  const setLocale = useSetLocale();

  return (
    <div>
      <button onClick={() => setLocale("en")}>English</button>
      <button onClick={() => setLocale("fr")}>Francais</button>
      <button onClick={() => setLocale("tr")}>Turkce</button>
    </div>
  );
}

Wenn setLocale aufgerufen wird:

1. Wird ein locale-Cookie für serverseitige Persistenz bei der nächsten Navigation gesetzt
2. Werden die neuen Übersetzungen vom CDN auf dem Client abgerufen
3. Wird der gesamte Baum mit der neuen Locale und den neuen Nachrichten neu gerendert — kein Seitenneuladen

Einen dynamischen Sprachauswähler erstellen

Verwenden Sie den useManifestLanguages-Hook, um einen Sprachauswähler zu erstellen, der automatisch die in Ihrem Better i18n-Projekt konfigurierten Sprachen widerspiegelt:

"use client";

import { useManifestLanguages, useSetLocale } from "@better-i18n/next/client";

export function DynamicLanguagePicker() {
  const { languages, isLoading, error } = useManifestLanguages({
    project: "acme/dashboard",
    defaultLocale: "en",
  });
  const setLocale = useSetLocale();

  if (isLoading) return <div>Sprachen werden geladen...</div>;
  if (error) return <div>Sprachen konnten nicht geladen werden</div>;

  return (
    <select onChange={(e) => setLocale(e.target.value)}>
      {languages.map((lang) => (
        <option key={lang.code} value={lang.code}>
          {lang.nativeName || lang.name || lang.code}
        </option>
      ))}
    </select>
  );
}

Die Sprachenliste wird vom CDN-Manifest mit eingebautem Request-Deduplication abgerufen — mehrere Komponenten, die useManifestLanguages aufrufen, teilen sich eine einzige Netzwerkanfrage.

8. SEO: hreflang, Canonical URLs und Metadata

Ein korrektes SEO-Setup ist für mehrsprachige Next.js-Apps entscheidend. So richten Sie hreflang-Tags und kanonische URLs ein. Für eine umfassende Aufschlüsselung, wie dies in eine breitere mehrsprachige SEO-Strategie passt, lesen Sie unseren localization SEO strategy guide.

Bei der Planung der gesamten Informationsarchitektur Ihrer mehrsprachigen App behandelt ein multilingual website design guide locale-bewusste Navigationsmuster, Textexpansion über Sprachen hinweg und RTL-Skript-Überlegungen, die direkt in die hier aufgebaute Struktur einfließen.

hreflang-Tags generieren

Fügen Sie alternative Sprachlinks in Ihrem Root-Layout oder in den Seiten-Metadaten hinzu:

// app/[locale]/layout.tsx
import { i18n } from "@/i18n/config";
import type { Metadata } from "next";

export async function generateMetadata({
  params,
}: {
  params: { locale: string };
}): Promise<Metadata> {
  const { locale } = await params;
  const locales = await i18n.getLocales();

  const languages: Record<string, string> = {};
  for (const loc of locales) {
    languages[loc] = `https://yourdomain.com/${loc}`;
  }
  // x-default für Suchmaschinen hinzufügen
  languages["x-default"] = "https://yourdomain.com/en";

  return {
    alternates: {
      canonical: `https://yourdomain.com/${locale}`,
      languages,
    },
  };
}

Dies generiert folgendes in Ihrem HTML:

<link rel="alternate" hreflang="en" href="https://yourdomain.com/en" />
<link rel="alternate" hreflang="fr" href="https://yourdomain.com/fr" />
<link rel="alternate" hreflang="tr" href="https://yourdomain.com/tr" />
<link rel="alternate" hreflang="x-default" href="https://yourdomain.com/en" />
<link rel="canonical" href="https://yourdomain.com/en" />

Lokalisierte Metadata

Servieren Sie übersetzte Seitentitel und -beschreibungen für jede Locale:

// app/[locale]/page.tsx
import { getTranslations } from "next-intl/server";
import type { Metadata } from "next";

export async function generateMetadata({
  params,
}: {
  params: { locale: string };
}): Promise<Metadata> {
  const t = await getTranslations("meta");

  return {
    title: t("home.title"),
    description: t("home.description"),
    openGraph: {
      title: t("home.title"),
      description: t("home.description"),
    },
  };
}

9. Offline-Fallback und Resilienz

Produktions-Apps müssen CDN-Ausfälle elegant handhaben. @better-i18n/next bietet eine dreistufige Fallback-Kette für sowohl Manifest- als auch Übersetzungsdaten:

1. Memory-Cache — In-Process-TTL-Cache (am schnellsten)
2. CDN-Abruf — Mit konfigurierbarem Timeout und Wiederholung
3. Persistenter Speicher — Für Offline-/verschlechterte Szenarien
4. Statische Daten — Gebündelte Übersetzungen als letzter Ausweg

// i18n/config.ts
import { createI18n } from "@better-i18n/next";

export const i18n = createI18n({
  project: "acme/dashboard",
  defaultLocale: "en",
  fetchTimeout: 5000,       // CDN-Abruf nach 5s abbrechen
  retryCount: 2,            // Bei Fehler zweimal wiederholen
  staticData: {             // Gebündelter Fallback
    en: {
      common: { error: "Etwas ist schief gelaufen" },
    },
  },
});

Wenn das CDN nicht erreichbar ist, werden Übersetzungen aus dem persistenten Speicher (falls konfiguriert) serviert oder fallen auf die gebündelten staticData zurück. Ihre App zeigt Benutzern niemals fehlerhafte Schlüssel.

10. KI-gestützte Übersetzung mit MCP

Better i18n enthält einen MCP (Model Context Protocol)-Server, der es KI-Assistenten ermöglicht, Ihre Übersetzungen direkt zu verwalten. Anstatt Übersetzungsdateien manuell zu schreiben, können Sie Claude, Cursor oder jedes MCP-kompatible Tool verwenden, um:

• Übersetzungsschlüssel zu erstellen mit createKeys
• Neue Sprachen vorzuschlagen mit proposeLanguages
• Bestehende Übersetzungen zu aktualisieren mit updateKeys
• Auf CDN zu veröffentlichen mit publishTranslations

Beispiel-Workflow

1. Sie schreiben Ihre React-Komponente mit englischen Strings
2. Fragen Sie Ihren KI-Assistenten: „Französische und türkische Übersetzungen für die Startseite hinzufügen"
3. Der MCP-Server erstellt die Schlüssel, schlägt Übersetzungen vor und veröffentlicht sie
4. Ihre Next.js-App übernimmt die neuen Übersetzungen beim nächsten ISR-Revalidierungszyklus (standardmäßig 30 Sekunden)

Kein manuelles JSON-Bearbeiten. Kein Kopieren und Einfügen zwischen Dateien. Der gesamte Übersetzungsworkflow läuft über Ihren KI-Coding-Assistenten. Um diesen Workflow mit unserem eigenen Blog-Inhalt in Aktion zu sehen, lesen Sie how we use AI to write our own blog.

Sobald Ihre Übersetzungen in allen Sprachen live sind, lohnt es sich, einen dedizierten i18n testing pass durchzuführen — automatisierte Prüfungen fangen fehlende Schlüssel, fehlerhafte Interpolationen und Pluralisierungsrandfälle ab, bevor sie Nutzer erreichen. Und wenn Ihre Strings Nuancen benötigen — UI-Labels, die je nach Ton oder Kontext variieren — behandelt unser Beitrag über why translation context matters, wie Sie diesen Kontext KI-Übersetzern effektiv bereitstellen.

Alles zusammenführen

Hier ist die vollständige Dateistruktur für ein Next.js App Router-Projekt mit Better i18n:

your-app/
  i18n/
    config.ts          # createI18n-Konfiguration
    request.ts         # next-intl-Request-Konfiguration
  middleware.ts        # Locale-Erkennung & Routing
  app/
    [locale]/
      layout.tsx       # BetterI18nProvider-Wrapper
      page.tsx         # Server Component mit getTranslations
      components/
        LanguageSwitcher.tsx  # Clientseitiges Locale-Wechseln

Kurzreferenz

// i18n/config.ts
import { createI18n } from "@better-i18n/next";
export const i18n = createI18n({
  project: "acme/dashboard",
  defaultLocale: "en",
  localePrefix: "as-needed",
});

// i18n/request.ts
import { i18n } from "./config";
export default i18n.requestConfig;

// middleware.ts
import { i18n } from "./i18n/config";
export default i18n.betterMiddleware();
export const config = {
  matcher: ["/((?!api|_next|.*\\..*).*)`"],
};

Häufige Fallstricke (und wie man sie vermeidet)

Nachdem wir Hunderten von Teams bei der Einrichtung von i18n in Next.js geholfen haben, sind dies die häufigsten Probleme:

1. Hydratationsfehlanpassungen bei Datums-/Zeitformatierung

Wenn Sie Datums- oder Zeitangaben ohne timeZone formatieren, können Server und Client unterschiedliche Werte rendern — was zu React-Hydratationsfehlern führt.

Lösung: Setzen Sie immer timeZone in Ihrer createI18n-Konfiguration:

createI18n({
  project: "acme/dashboard",
  defaultLocale: "en",
  timeZone: "UTC", // Verhindert Server/Client-Fehlanpassung
});

Better i18n setzt dies automatisch in der Request-Konfiguration und im BetterI18nProvider, fällt auf Intl.DateTimeFormat().resolvedOptions().timeZone zurück, wenn Sie keines angeben.

2. Fehlendes Locale-Prefix bei Standard-Locale

Mit localePrefix: "as-needed" (Standard) hat Ihre Standard-Locale kein URL-Prefix. Das bedeutet, /about serviert Englisch, aber /fr/about serviert Französisch. Wenn Sie das vergessen und Locale-Segmente in Links hartcodieren, wird Ihre Standard-Locale kaputt gehen.

Lösung: Verwenden Sie next-intls Link-Komponente oder erstellen Sie Pfade dynamisch:

// So:
<Link href="/about">{t("nav.about")}</Link>

// Nicht so:
<a href="/en/about">About</a>

3. Cookie wird nicht über Subdomains hinweg persistiert

Das Standard-locale-Cookie wird mit path: / gesetzt, aber ohne domain. Wenn Ihre App Subdomains überspannt (z.B. app.yourdomain.com und www.yourdomain.com), wird das Cookie nicht geteilt.

Lösung: Für Multi-Subdomain-Setups verwenden Sie localePrefix: "always", damit die Locale immer in der URL ist, oder setzen Sie eine benutzerdefinierte Cookie-Domain in Ihrem Middleware-Callback.

4. Middleware-Matcher schließt statische Dateien nicht aus

Wenn Ihr Middleware-Matcher zu weit gefasst ist, läuft er bei jeder Anfrage — einschließlich Bilder, Schriften und API-Routen. Das verlangsamt Ihre App und kann zu unerwarteten Locale-Weiterleitungen führen.

Lösung: Verwenden Sie immer das empfohlene Matcher-Muster:

export const config = {
  matcher: ["/((?!api|_next|.*\\..*).*)`"],
};

Dies schließt /api/*, /_next/* und jeden Pfad mit einer Dateiendung aus.

Fazit

Die Einrichtung von i18n im Next.js App Router muss nicht schmerzhaft sein. Mit @better-i18n/next erhalten Sie:

• Zero-Config-Locale-Erkennung aus URL, Cookies und Browser-Headern
• CDN-gestützte Übersetzungen mit ISR-Caching und Offline-Fallback
• Kompositionsfähige Middleware die gut mit Auth zusammenspielt (Clerk, NextAuth, etc.)
• Sofortiges clientseitiges Locale-Wechseln ohne Seitenneuladen
• SEO-bereit mit hreflang, kanonischen URLs und lokalisierten Metadaten
• KI-gestützte Übersetzung durch die MCP-Server-Integration

Das gesamte Setup benötigt fünf Dateien und unter 50 Zeilen Konfigurationscode. Ihre Übersetzungen werden von einem globalen CDN serviert, mit ISR gecacht und über Ihren KI-Assistenten verwaltet.

Bereit loszulegen? Installieren Sie @better-i18n/next und bringen Sie Ihre erste Locale in Minuten zum Laufen:

npm install @better-i18n/next next-intl

Schauen Sie sich die vollständige Dokumentation an oder erkunden Sie das GitHub-Repository für fortgeschrittenere Muster.

Verwandte Ressourcen

• Next.js i18n Landing Page — Funktionsübersicht und Vergleich
• i18n for Developers — Warum Better i18n entwicklerorientiert aufgebaut ist
• CLI Code Scanning — Hartcodierte Strings abfangen, bevor sie ausgeliefert werden