@intlayer/docs 5.8.0-canary.0 → 5.8.1-canary.0

package/blog/de/react-i18next_vs_react-intl_vs_intlayer.md

@@ -1,14 +1,14 @@
 ---
 createdAt: 2025-01-02
 updatedAt: 2025-06-29
-title: react-i18n vs react-intl vs Intlayer
-description: Integrieren Sie react-i18next mit next-intl und Intlayer für die Internationalisierung (i18n) einer React-App
+title: react-i18next vs react-intl vs Intlayer
+description: Integration von react-i18next mit next-intl und Intlayer für die Internationalisierung (i18n) einer React-App
 keywords:
   - next-intl
   - react-i18next
   - Intlayer
   - Internationalisierung
-  - Dokumentation
+  - Blog
   - Next.js
   - JavaScript
   - React
@@ -17,178 +17,137 @@ slugs:
   - react-i18next-vs-react-intl-vs-intlayer
 ---
 
-# React-Intl VS React-i18next VS Intlayer | React Internationalisierung (i18n)
+# react-Intl VS react-i18next VS Intlayer | React Internationalisierung (i18n)
 
-Nachfolgend finden Sie einen prägnanten Vergleich von drei beliebten i18n (Internationalisierungs-) Bibliotheken für React: **React-Intl**, **React-i18next** und **Intlayer**. Jede Bibliothek bietet einzigartige Funktionen und Arbeitsabläufe zur Integration von mehrsprachiger Unterstützung in Ihre React-Anwendung. Nach dem Lesen sollten Sie in der Lage sein zu entscheiden, welche Lösung am besten zu Ihren Bedürfnissen passt.
+Dieser Leitfaden vergleicht drei etablierte i18n-Optionen für **React**: **react-intl** (FormatJS), **react-i18next** (i18next) und **Intlayer**.
+Wir konzentrieren uns auf **reine React**-Anwendungen (z. B. Vite, CRA, SPA). Wenn Sie Next.js verwenden, sehen Sie unseren speziellen Next.js-Vergleich.
 
----
-
-## 1. Einführung
-
-Internationalisierung (i18n) in React-Anwendungen kann auf verschiedene Weisen erreicht werden. Die drei hier vorgestellten Bibliotheken haben unterschiedliche Entwurfsphilosophien, Funktionen und Community-Unterstützung:
+Wir bewerten:
 
-1. **React-Intl**
-2. **React-i18next**
-3. **Intlayer**
+- Architektur & Inhaltsorganisation
+- TypeScript & Sicherheit
+- Umgang mit fehlenden Übersetzungen
+- Umfangreiche Inhalts- & Formatierungsfunktionen
+- Leistung & Ladeverhalten
+- Entwicklererfahrung (DX), Tools & Wartung
+- SEO/Routing (frameworkabhängig)
 
-Unten finden Sie eine Übersicht über jede Lösung, gefolgt von einem Funktionsvergleich, Vor- und Nachteilen sowie Anwendungsbeispielen.
+> **Kurzfassung**: Alle drei können eine React-App lokalisieren. Wenn Sie **komponentenbezogenen Inhalt**, **strenge TypeScript-Typen**, **Build-Zeit-Prüfungen auf fehlende Schlüssel**, **baumgeschüttelte Wörterbücher** und integrierte redaktionelle Werkzeuge (Visueller Editor/CMS + optionale KI-Übersetzung) wünschen, ist **Intlayer** die vollständigste Wahl für modulare React-Codebasen.
 
 ---
 
-## 2. React-Intl
-
-### Übersicht
-
-[**React-Intl**](https://formatjs.io/docs/react-intl/) ist Teil der [FormatJS](https://formatjs.io/) Suite. Es bietet eine leistungsstarke Reihe von **APIs und Komponenten**, um die Nachrichtenformatierung, Pluralisierung, Datums-/Zeitformatierung und Zahlenformatierung zu verwalten. React-Intl wird häufig in Unternehmensanwendungen verwendet, hauptsächlich weil es Teil eines Ökosystems ist, das die Syntax und Formatierung von Nachrichten standardisiert.
-
-### Hauptmerkmale
-
-- **ICU-Nachrichtensyntax**: Bietet eine umfassende Syntax für die Nachrichteninterpolation, Pluralisierung und mehr.
-- **Lokalisierte Formatierung**: Eingebaute Dienstprogramme zur Formatierung von Daten, Zeiten, Zahlen und relativen Zeiten basierend auf der Lokalisierung.
-- **Deklarative Komponenten**: Stellt `<FormattedMessage>`, `<FormattedNumber>`, `<FormattedDate>` usw. für eine nahtlose Verwendung in JSX zur Verfügung.
-- **Reiches Ökosystem**: Integriert sich gut mit den FormatJS-Tools (z. B. [babel-plugin-react-intl](https://formatjs.io/docs/tooling/babel-plugin/)) zum Extrahieren, Verwalten und Kompilieren von Nachrichten.
-
-### Typischer Arbeitsablauf
-
-1. **Definieren Sie Nachrichtenkataloge** (normalerweise JSON-Dateien pro Lokalisierung).
-2. **Wickeln Sie Ihre App** in `<IntlProvider locale="de" messages={messages}>`.
-3. **Verwenden Sie** `<FormattedMessage id="myMessage" defaultMessage="Hallo Welt" />` oder den `useIntl()` Hook, um auf Übersetzungsstrings zuzugreifen.
-
-### Vorteile
-
-- Gut etabliert und wird in vielen Produktionsumgebungen eingesetzt.
-- Fortschrittliche Nachrichtenformatierung, einschließlich Pluralisierung, Geschlecht, Zeitzonen und mehr.
-- Starke Unterstützung durch Werkzeuge zur Extraktion und Kompilierung von Nachrichten.
-
-### Nachteile
+## Übergeordnete Positionierung
 
-- Erfordert Vertrautheit mit dem **ICU-Nachrichtenformat**, das ausführlich sein kann.
-- Es ist nicht so einfach, dynamische oder komplexe Übersetzungen zu handhaben, die mehr als nur stringbasiert sind.
+- **react-intl** - ICU-first, standardkonforme Formatierung (Datum/Zahlen/Pluralformen) mit einer ausgereiften API. Kataloge sind typischerweise zentralisiert; Schlüssel-Sicherheit und Build-Zeit-Validierung liegen größtenteils bei Ihnen.
+- **react-i18next** - Extrem beliebt und flexibel; Namespaces, Detektoren und viele Plugins (ICU, Backends). Leistungsstark, aber die Konfiguration kann mit wachsendem Projektumfang umfangreich werden.
+- **Intlayer** - Komponentenorientiertes Inhaltsmodell für React, **strenge TS-Typisierung**, **Build-Zeit-Prüfungen**, **Tree-Shaking**, plus **Visueller Editor/CMS** und **KI-unterstützte Übersetzungen**. Funktioniert mit React Router, Vite, CRA usw.
 
 ---
 
-## 3. React-i18next
+## Funktionsmatrix (React-Fokus)
+
+| Funktion                                           | `react-intlayer` (Intlayer)                                                                                                                       | `react-i18next` (i18next)                                                                                                          | `react-intl` (FormatJS)                                                                                             |
+| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| **Übersetzungen in der Nähe der Komponenten**      | ✅ Ja, Inhalte sind mit jeder Komponente zusammengefasst                                                                                          | ❌ Nein                                                                                                                            | ❌ Nein                                                                                                             |
+| **TypeScript-Integration**                         | ✅ Fortgeschritten, automatisch generierte strenge Typen                                                                                          | ⚠️ Grundlegend; zusätzliche Konfiguration für Sicherheit                                                                           | ✅ Gut, aber weniger streng                                                                                         |
+| **Fehlende Übersetzungs-Erkennung**                | ✅ TypeScript-Fehlerhervorhebung und Build-Zeit Fehler/Warnung                                                                                    | ⚠️ Meistens Fallback-Strings zur Laufzeit                                                                                          | ⚠️ Fallback-Strings                                                                                                 |
+| **Reicher Inhalt (JSX/Markdown/Komponenten)**      | ✅ Direkte Unterstützung                                                                                                                          | ⚠️ Eingeschränkt / nur Interpolation                                                                                               | ⚠️ ICU-Syntax, kein echtes JSX                                                                                      |
+| **KI-gestützte Übersetzung**                       | ✅ Ja, unterstützt mehrere KI-Anbieter. Nutzbar mit eigenen API-Schlüsseln. Berücksichtigt den Kontext Ihrer Anwendung und den Umfang des Inhalts | ❌ Nein                                                                                                                            | ❌ Nein                                                                                                             |
+| **Visueller Editor**                               | ✅ Ja, lokaler visueller Editor + optionales CMS; kann Codebasis-Inhalte auslagern; einbettbar                                                    | ❌ Nein / verfügbar über externe Lokalisierungsplattformen                                                                         | ❌ Nein / verfügbar über externe Lokalisierungsplattformen                                                          |
+| **Lokalisierte Routenführung**                     | ✅ Ja, unterstützt lokalisierte Pfade direkt (funktioniert mit Next.js & Vite)                                                                    | ⚠️ Nicht eingebaut, erfordert Plugins (z.B. `next-i18next`) oder benutzerdefinierte Router-Konfiguration                           | ❌ Nein, nur Nachrichtenformatierung, Routing muss manuell erfolgen                                                 |
+| **Dynamische Routen-Generierung**                  | ✅ Ja                                                                                                                                             | ⚠️ Plugin/Ökosystem oder manuelle Einrichtung                                                                                      | ❌ Nicht bereitgestellt                                                                                             |
+| **Pluralisierung**                                 | ✅ Aufzählungsbasierte Muster                                                                                                                     | ✅ Konfigurierbar (Plugins wie i18next-icu)                                                                                        | ✅ (ICU)                                                                                                            |
+| **Formatierung (Daten, Zahlen, Währungen)**        | ✅ Optimierte Formatierer (Intl im Hintergrund)                                                                                                   | ⚠️ Über Plugins oder benutzerdefinierte Intl-Nutzung                                                                               | ✅ ICU-Formatierer                                                                                                  |
+| **Inhaltsformat**                                  | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml in Arbeit)                                                                                            | ⚠️ .json                                                                                                                           | ✅ .json, .js                                                                                                       |
+| **ICU-Unterstützung**                              | ⚠️ In Arbeit                                                                                                                                      | ⚠️ Über Plugin (i18next-icu)                                                                                                       | ✅ Ja                                                                                                               |
+| **SEO-Helfer (hreflang, Sitemap)**                 | ✅ Eingebaute Werkzeuge: Helfer für Sitemap, robots.txt, Metadaten                                                                                | ⚠️ Community-Plugins / manuell                                                                                                     | ❌ Nicht im Kern                                                                                                    |
+| **Ökosystem / Community**                          | ⚠️ Kleiner, aber schnell wachsend und reaktiv                                                                                                     | ✅ Größte und ausgereifte                                                                                                          | ✅ Groß                                                                                                             |
+| **Server-seitiges Rendering & Server-Komponenten** | ✅ Ja, optimiert für SSR / React Server-Komponenten                                                                                               | ⚠️ Unterstützt auf Seitenebene, aber t-Funktionen müssen im Komponentenbaum für untergeordnete Server-Komponenten übergeben werden | ❌ Nicht unterstützt, t-Funktionen müssen im Komponentenbaum für untergeordnete Server-Komponenten übergeben werden |
+| **Tree-shaking (nur genutzte Inhalte laden)**      | ✅ Ja, pro Komponente zur Build-Zeit über Babel/SWC-Plugins                                                                                       | ⚠️ Lädt normalerweise alles (kann mit Namespaces/Code-Splitting verbessert werden)                                                 | ⚠️ Lädt normalerweise alles                                                                                         |
+| **Lazy Loading**                                   | ✅ Ja, pro Sprache / pro Wörterbuch                                                                                                               | ✅ Ja (z.B. Backends/Namespaces bei Bedarf)                                                                                        | ✅ Ja (aufgeteilte Sprachpakete)                                                                                    |
+| **Bereinigung ungenutzter Inhalte**                | ✅ Ja, pro Wörterbuch zur Build-Zeit                                                                                                              | ❌ Nein, nur durch manuelle Namespace-Segmentierung                                                                                | ❌ Nein, alle deklarierten Nachrichten werden gebündelt                                                             |
+| **Verwaltung großer Projekte**                     | ✅ Fördert Modularität, geeignet für Design-Systeme                                                                                               | ⚠️ Benötigt gute Dateidisziplin                                                                                                    | ⚠️ Zentrale Kataloge können sehr groß werden                                                                        |
 
-### Übersicht
-
-[**React-i18next**](https://react.i18next.com/) ist eine React-Erweiterung von [i18next](https://www.i18next.com/), einem der beliebtesten JavaScript-i18n-Frameworks. Es bietet **umfangreiche Funktionen** für Laufzeitübersetzungen, Lazy Loading und Spracherkennung, was es extrem flexibel für eine Vielzahl von Anwendungsfällen macht.
-
-### Hauptmerkmale
-
-- **Flexible Übersetzungsstruktur**: Nicht an ein einzelnes Format wie ICU gebunden. Sie können Übersetzungen in JSON speichern, Interpolation, Pluralisierung usw. verwenden.
-- **Dynamischer Sprachwechsel**: Eingebaute Sprachdetektor-Plugins und Laufzeitaktualisierungen.
-- **Verschachtelte & strukturierte Übersetzungen**: Sie können Übersetzungen leicht innerhalb von JSON verschachteln.
-- **Umfangreiches Plugin-Ökosystem**: Für Erkennung (Browser, Pfad, Subdomain usw.), Ressourcenladen, Caching und mehr.
-
-### Typischer Arbeitsablauf
-
-1. **Installieren Sie `i18next` & `react-i18next`.**
-2. **Konfigurieren Sie i18n**, um Übersetzungen zu laden (JSON) und die Spracherkennung oder Fallbacks einzurichten.
-3. **Wickeln Sie Ihre App** in `I18nextProvider`.
-4. **Verwenden Sie den `useTranslation()` Hook** oder die `<Trans>`-Komponente, um Übersetzungen anzuzeigen.
+---
 
-### Vorteile
+## Tiefgehender Vergleich
 
-- Sehr **flexibel** und funktionsreich.
-- Sehr aktive Community und großes Ökosystem von Plugins.
-- Einfachheit des **dynamischen Ladens** von Übersetzungen (z. B. von einem Server, nach Bedarf).
+### 1) Architektur & Skalierbarkeit
 
-### Nachteile
+- **react-intl / react-i18next**: Die meisten Setups pflegen **zentralisierte Sprachordner** pro Sprache, manchmal aufgeteilt in **Namespaces** (i18next). Funktioniert anfangs gut, wird aber mit wachsender App zu einer gemeinsam genutzten Oberfläche.
+- **Intlayer**: Fördert **pro-Komponente (oder pro-Feature) Wörterbücher**, die **direkt neben der UI** liegen, die sie bedienen. Dies sorgt für klare Verantwortlichkeiten, erleichtert die Duplizierung/Migration von Komponenten und reduziert den Schlüsselwechsel zwischen Teams. Unbenutzte Inhalte sind leichter zu erkennen und zu entfernen.
 
-- **Konfiguration kann ausführlich sein**, insbesondere wenn Sie fortschrittlichere Bedürfnisse haben.
-- Wenn Sie stark typisierte Übersetzungen bevorzugen, benötigen Sie möglicherweise zusätzliche TypeScript-Konfigurationen.
+**Warum das wichtig ist:** Modularer Inhalt spiegelt modulare UI wider. Große React-Codebasen bleiben sauberer, wenn Übersetzungen bei den Komponenten leben, zu denen sie gehören.
 
 ---
 
-## 4. Intlayer
+### 2) TypeScript & Sicherheit
 
-### Übersicht
+- **react-intl**: Solide Typisierung, aber **keine automatische Schlüsseltypisierung**; Sicherheitsmuster müssen selbst durchgesetzt werden.
+- **react-i18next**: Starke Typisierung für Hooks; **strikte Schlüsseltypisierung** erfordert typischerweise zusätzliche Konfiguration oder Generatoren.
+- **Intlayer**: **Generiert automatisch strenge Typen** aus Ihrem Inhalt. Die IDE-Autovervollständigung und **Kompilierzeit-Fehler** erkennen Tippfehler und fehlende Schlüssel vor der Laufzeit.
 
-[**Intlayer**](https://github.com/aymericzip/intlayer) ist eine neuere, Open-Source-i18n-Bibliothek, die sich auf **komponentenbasierte Inhaltsdeklarationen**, Typsicherheit und **dynamisches Routing** konzentriert. Sie ist für moderne React-Arbeitsabläufe konzipiert und unterstützt sowohl **Create React App** als auch **Vite**-Setups. Außerdem sind fortschrittliche Funktionen wie **lokalisierte Routen** und **automatisch generierte TypeScript-Typen** für Übersetzungen enthalten.
+**Warum das wichtig ist:** Das Verschieben von Fehlern nach **links** (zum Build/CI) reduziert Produktionsprobleme und beschleunigt die Feedback-Schleifen für Entwickler.
 
-### Hauptmerkmale
+---
 
-- **Deklarative Inhaltsdateien**: Jede Komponente oder jedes Modul kann seine Übersetzungen in eigenen `.content.tsx` oder `.content.json`-Dateien deklarieren, um den Inhalt in der Nähe der Nutzung zu halten.
-- **Eingebaute Routen & Middleware**: Optionale Module für lokalisiertes Routing (z. B. `/de/about`, `/fr/about`) und Server-Middleware zur Erkennung der Benutzersprache.
-- **Automatisch generierte TypeScript-Typen**: Sicherstellt Typsicherheit mit Funktionen wie Autovervollständigung und Compile-Time-Fehlererkennung.
-- **Dynamische & reiche Übersetzungen**: Können JSX/TSX in Übersetzungen für komplexere Anwendungsfälle (z. B. Links, kursiven Text, Icons in Übersetzungen) einbeziehen.
+### 3) Umgang mit fehlenden Übersetzungen
 
-### Typischer Arbeitsablauf
+- **react-intl / react-i18next**: Standardmäßig **Laufzeit-Fallbacks** (Schlüssel-Echo oder Standardsprache). Sie können Linting/Plugins hinzufügen, aber es ist nicht garantiert, dass dies beim Build passiert.
+- **Intlayer**: **Build-Zeit-Erkennung** mit Warnungen oder Fehlern, wenn erforderliche Sprachen/Schlüssel fehlen.
 
-1. **Installieren Sie `intlayer` und `react-intlayer`.**
-2. **Erstellen Sie `intlayer.config.ts`**, um verfügbare Sprachen und die Standard-Sprache zu definieren.
-3. **Verwenden Sie die Intlayer CLI** oder das Plugin, um **Inhaltsdeklarationen zu transpilen**.
-4. **Wickeln Sie Ihre App** in `<IntlayerProvider>` und rufen Sie Inhalte mit `useIntlayer("keyName")` ab.
+**Warum das wichtig ist:** Ein fehlschlagender CI-Prozess bei fehlenden Strings verhindert, dass „mysteriöses Englisch“ in nicht-englische UIs gelangt.
 
-### Vorteile
+---
 
-- **TypeScript-freundlich** mit integrierter Typerzeugung und Fehlerüberprüfung.
-- **Reicher Inhalt** möglich (z. B. Übergeben von React-Knoten als Übersetzungen).
-- **Lokalisierte Routen** sofort einsatzbereit.
-- Integriert mit beliebten Build-Tools (CRA, Vite) für eine einfache Einrichtung.
+### 4) Reichhaltiger Inhalt & Formatierung
 
-### Nachteile
+- **react-intl**: Hervorragende **ICU**-Unterstützung für Pluralformen, Auswahlmöglichkeiten, Datums-/Zahlenformate und Nachrichtenkomposition. JSX kann verwendet werden, aber das mentale Modell bleibt nachrichtenorientiert.
+- **react-i18next**: Flexible Interpolation und **`<Trans>`** zum Einbetten von Elementen/Komponenten; ICU ist über ein Plugin verfügbar.
+- **Intlayer**: Inhaltsdateien können **reiche Knoten** (JSX/Markdown/Komponenten) und **Metadaten** enthalten. Die Formatierung verwendet intern Intl; Pluralmuster sind ergonomisch.
 
-- Noch **relativ neu** im Vergleich zu React-Intl oder React-i18next.
-- Schwerer Fokus auf den Ansatz der „komponentenbasierten Inhaltsdeklaration“ – kann eine Abweichung von typischen .json-Katalogen sein.
-- Kleinere Ökosystem und Community im Vergleich zu den etablierten Bibliotheken.
+**Warum das wichtig ist:** Komplexe UI-Texte (Links, fettgedruckte Teile, Inline-Komponenten) sind einfacher zu handhaben, wenn die Bibliothek React-Knoten sauber unterstützt.
 
 ---
 
-## 5. Funktionsvergleich
+### 5) Leistung & Ladeverhalten
+
+- **react-intl / react-i18next**: Sie verwalten typischerweise **Katalogaufteilung** und **Lazy Loading** manuell (Namespaces/dynamische Importe). Effektiv, erfordert aber Disziplin.
+- **Intlayer**: **Entfernt ungenutzte Wörterbücher** automatisch (Tree-shaking) und unterstützt **Lazy Loading pro Wörterbuch/pro Sprache** direkt out-of-the-box.
 
-| **Funktion**                      | **React-Intl**                                                                           | **React-i18next**                                                                                                   | **Intlayer**                                                                                                                                                |
-| --------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Primärer Anwendungsfall**       | Stringbasierte Übersetzungen, Daten-/Zahlenformatierung, ICU-Nachrichtensyntax           | Vollwertige i18n mit einfachem dynamischem Wechsel, Verschachtelung, Plugin-Ökosystem                               | Typensichere Übersetzungen mit Fokus auf deklarativen Inhalt, lokalisierten Routen & optionaler Server-Middleware                                           |
-| **Ansatz**                        | Nutzung von `<IntlProvider>` & FormatJS-Nachrichtenkomponenten                           | Nutzung von `I18nextProvider` & `useTranslation()`-Hook                                                             | Nutzung von `<IntlayerProvider>` & `useIntlayer()`-Hook mit Inhaltsdeklarationen                                                                            |
-| **Lokalisierungsformat**          | ICU-basierte Strings (JSON oder JavaScript-Kataloge)                                     | JSON-Ressourcendateien (oder benutzerdefinierte Loader). ICU-Format optional über i18next-Plugin                    | `.content.[ts/js/tsx]` oder JSON-Deklarationen; kann Strings oder React-Komponenten enthalten                                                               |
-| **Routing**                       | Extern behandelt (kein integriertes lokales Routing)                                     | Extern mit i18next-Plugins (Pfad-, Subdomainerkennung usw.)                                                         | Eingebaute Unterstützung für lokales Routing (z. B. `/de/about`, `/fr/about`), plus optionale Server-Middleware (für SSR/Vite)                              |
-| **TypeScript Unterstützung**      | Gut (Typisierung für offizielle Pakete)                                                  | Gut, aber zusätzliche Konfiguration für typisierte Übersetzungen, wenn Sie strenge Überprüfungen wünschen           | Hervorragend (automatisch generierte Typdefinitionen für Inhaltsschlüssel und Übersetzungen)                                                                |
-| **Pluralisierung & Formatierung** | Fortgeschritten: Eingebaute Daten-/Zahlenformatierung, Plural-/ Geschlechtsunterstützung | Konfigurierbare Pluralisierung. Datums-/Zeitformatierung in der Regel über externe Bibliotheken oder i18next-Plugin | Kann auf Standard-JavaScript-Intl angewiesen sein oder Logik in den Inhalten einbetten. Nicht so spezialisiert wie FormatJS, behandelt aber typische Fälle. |
-| **Community & Ökosystem**         | Groß, Teil des FormatJS-Ökosystems                                                       | Sehr groß, sehr aktiv, viele Plugins (Erkennung, Caching, Frameworks)                                               | Kleiner, aber wachsend; Open Source, moderner Ansatz                                                                                                        |
-| **Lernkurve**                     | Mäßig (Lernen der ICU-Nachrichtensyntax, FormatJS-Konventionen)                          | Niedrig bis mäßig (gerade Nutzung, aber fortschrittliche Konfiguration kann ausführlich werden)                     | Mäßig (Konzept der Inhaltsdeklarationen und spezialisierte Build-Schritte)                                                                                  |
+**Warum das wichtig ist:** Kleinere Bundles und weniger ungenutzte Strings verbessern die Start- und Navigationsleistung.
 
 ---
 
-## 6. Wann man jede wählen sollte
+### 6) DX, Tooling & Wartung
 
-1. **React-Intl**
+- **react-intl / react-i18next**: Breites Community-Ökosystem; für redaktionelle Workflows verwendet man üblicherweise externe Lokalisierungsplattformen.
+- **Intlayer**: Bietet einen **kostenlosen Visual Editor** und ein **optionales CMS** (Inhalte in Git behalten oder auslagern). Außerdem gibt es eine **VSCode-Erweiterung** für die Inhaltserstellung und **KI-unterstützte Übersetzung** mit eigenen Anbieter-Schlüsseln.
 
-   - Sie benötigen **leistungsstarkes Formatieren** für Daten/Zeit/Zahlen und starke **ICU-Nachrichtensyntax**.
-   - Sie bevorzugen einen „**standardsbasierten**“ Ansatz für Übersetzungen.
-   - Sie benötigen kein lokales Routing oder stark typisierte Übersetzungsschlüssel.
+**Warum das wichtig ist:** Eingebaute Werkzeuge verkürzen den Kreislauf zwischen Entwicklern und Inhaltserstellern - weniger Klebecode, weniger Abhängigkeiten von Drittanbietern.
 
-2. **React-i18next**
+---
 
-   - Sie benötigen eine **flexible, etablierte** Lösung mit **dynamischer** und **on-demand** Übersetzungsbeladung.
-   - Sie möchten **pluginbasierte** Sprachenerkennung (z. B. von URL, Cookies, lokalem Speicher) oder fortschrittliches Caching.
-   - Sie benötigen das größte Ökosystem, mit vielen bestehenden Integrationen für verschiedene Frameworks (Next.js, React Native usw.).
+## Wann welches wählen?
 
-3. **Intlayer**
-   - Sie möchten eine **starke TypeScript**-Integration mit _automatisch generierten Typen_, um sicherzustellen, dass Sie in der Regel keinen Übersetzungsschlüssel übersehen.
-   - Sie bevorzugen **deklarative Inhalte** nahe der Komponente, möglicherweise mit React-Knoten oder fortgeschrittener Logik in Übersetzungen.
-   - Sie benötigen **eingebaute lokalisiertes Routing** oder möchten es einfach in Ihr SSR oder Vite-Setup integrieren.
-   - Sie wünschen sich einen modernen Ansatz oder möchten einfach eine einzige Bibliothek, die sowohl **Inhaltsverwaltung** (i18n) als auch **Routing** auf eine typsichere Weise abdeckt.
+- **Wählen Sie react-intl**, wenn Sie eine **ICU-first** Nachrichtenformatierung mit einer einfachen, standardkonformen API wünschen und Ihr Team damit vertraut ist, Kataloge und Sicherheitsprüfungen manuell zu pflegen.
+- **Wählen Sie react-i18next**, wenn Sie die **Vielfalt des i18next-Ökosystems** (Detektoren, Backends, ICU-Plugin, Integrationen) benötigen und mehr Konfiguration für mehr Flexibilität akzeptieren.
+- **Wählen Sie Intlayer**, wenn Sie **komponentenbezogenen Inhalt**, **striktes TypeScript**, **Build-Zeit-Garantien**, **Tree-Shaking** und **inklusive redaktionelle Werkzeuge** schätzen – besonders für **große, modulare** React-Anwendungen.
 
 ---
 
-## 7. Fazit
-
-Jede Bibliothek bietet eine robuste Lösung zur Internationalisierung einer React-Anwendung:
-
-- **React-Intl** ist hervorragend in der Nachrichtenformatierung und eine beliebte Wahl für Unternehmenslösungen, die auf ICU-Nachrichtensyntax fokussiert sind.
-- **React-i18next** bietet eine hochflexible, plugin-gesteuerte Umgebung für fortschrittliche oder dynamische i18n-Bedürfnisse.
-- **Intlayer** bietet einen **modernen, stark typisierten** Ansatz, der Inhaltsdeklarationen, fortgeschrittenes lokalisierte Routing und pluginbasierte (CRA, Vite) Integrationen vereint.
+## Praktische Migrationshinweise (react-intl / react-i18next → Intlayer)
 
-Ihre Wahl hängt weitgehend von den Projektanforderungen, dem gewünschten Entwicklererlebnis (DX) und der Bedeutung von typisierten Übersetzungen oder fortschrittlichem Routing ab. Wenn Sie eingebaute lokalisiertes Routing und TypeScript-Integration schätzen, ist **Intlayer** möglicherweise am ansprechendsten. Wenn Sie eine bewährte Lösung mit reichhaltigem Ökosystem wünschen, ist **React-i18next** eine großartige Wahl. Für straightforwarde Anforderungen an ICU-basiertes Formatieren ist **React-Intl** eine zuverlässige Option.
+- **Schrittweise migrieren**: Beginnen Sie mit einer Funktion oder Route; behalten Sie während der Umstellung die alten Kataloge parallel bei.
+- **Pro-Komponenten-Wörterbücher übernehmen**: Platzieren Sie Inhalte zusammen mit den Komponenten, um die Kopplung zu reduzieren.
+- **Strenge Prüfungen aktivieren**: Lassen Sie Build-Zeit-Fehler fehlende Schlüssel/Locales frühzeitig in der CI anzeigen.
+- **Bundles messen**: Erwarten Sie Reduzierungen, da ungenutzte Strings entfernt werden.
 
 ---
 
-### Weiterführende Literatur
+## Fazit
 
-- [React-Intl Dokumentation](https://formatjs.io/docs/react-intl/)
-- [React-i18next Dokumentation](https://react.i18next.com/)
-- [Intlayer + CRA Erste Schritte](#) (aus Ihrem Dokument)
-- [Intlayer + Vite & React Erste Schritte](#) (aus Ihrem Dokument)
+Alle drei Bibliotheken lokalisieren React effektiv. Der Unterschied liegt darin, wie viel **Infrastruktur** Sie aufbauen müssen, um eine **sichere, skalierbare** Umgebung zu erreichen:
 
-Fühlen Sie sich frei, Ansätze zu kombinieren und anzupassen, um Ihren Anforderungen gerecht zu werden – es gibt keine „One-Size-Fits-All“-Lösung, und jede Bibliothek entwickelt sich weiter, um neue Anwendungsfälle im React-Ökosystem zu adressieren.
+- Mit **Intlayer** sind **modularer Inhalt**, **strikte TS-Typisierung**, **Build-Zeit-Sicherheit**, **baumgeschüttelte Bundles** und **redaktionelle Werkzeuge** Standard - keine lästige Pflicht.
+- Wenn Ihr Team **Wartbarkeit und Geschwindigkeit** in mehrsprachigen, komponentenbasierten React-Anwendungen schätzt, bietet Intlayer heute den **vollständigsten** Entwickler- und Inhaltsworkflow.

package/blog/de/vue-i18n_vs_intlayer.md

@@ -0,0 +1,268 @@
+---
+createdAt: 2024-08-11
+updatedAt: 2025-08-23
+title: vue-i18n vs Intlayer
+description: Vergleich von vue-i18n mit Intlayer für Internationalisierung (i18n) in Vue/Nuxt-Apps
+keywords:
+  - vue-i18n
+  - Intlayer
+  - Internationalisierung
+  - i18n
+  - Blog
+  - Vue
+  - Nuxt
+  - JavaScript
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer
+---
+
+# vue-i18n VS Intlayer | Vue Internationalisierung (i18n)
+
+Dieser Leitfaden vergleicht zwei beliebte i18n-Optionen für **Vue 3** (und **Nuxt**): **vue-i18n** und **Intlayer**.
+Wir konzentrieren uns auf moderne Vue-Tools (Vite, Composition API) und bewerten:
+
+1. **Architektur & Inhaltsorganisation**
+2. **TypeScript & Sicherheit**
+3. **Umgang mit fehlenden Übersetzungen**
+4. **Routing- & URL-Strategie**
+5. **Performance & Ladeverhalten**
+6. **Entwicklererfahrung (DX), Tools & Wartung**
+7. **SEO & Skalierbarkeit für große Projekte**
+
+> **Kurzfassung**: Beide können Vue-Apps lokalisieren. Wenn Sie **komponentenbezogenen Inhalt**, **strenge TypeScript-Typen**, **Build-Zeit-Prüfungen für fehlende Schlüssel**, **tree-shakbare Wörterbücher** und **integrierte Router-/SEO-Hilfen** sowie **Visuellen Editor & KI-Übersetzungen** wünschen, ist **Intlayer** die umfassendere, modernere Wahl.
+
+---
+
+## Übergeordnete Positionierung
+
+- **vue-i18n** - Die de-facto i18n-Bibliothek für Vue. Flexible Nachrichtenformatierung (ICU-Stil), SFC-`<i18n>`-Blöcke für lokale Nachrichten und ein großes Ökosystem. Sicherheit und groß angelegte Wartung liegen größtenteils bei Ihnen.
+- **Intlayer** - Komponentenorientiertes Inhaltsmodell für Vue/Vite/Nuxt mit **strenger TS-Typisierung**, **Build-Zeit-Prüfungen**, **Tree-Shaking**, **Router- & SEO-Hilfen**, optionalem **Visuellen Editor/CMS** und **KI-unterstützten Übersetzungen**.
+
+---
+
+## Gegenüberstellung der Funktionen (Vue-fokussiert)
+
+| Funktion                                           | **Intlayer**                                                                                   | **vue-i18n**                                                                                               |
+| -------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| **Übersetzungen nahe bei den Komponenten**         | ✅ Ja, Inhalt pro Komponente zusammengefasst (z.B. `MyComp.content.ts`)                        | ✅ Ja, über SFC-`<i18n>`-Blöcke (optional)                                                                 |
+| **TypeScript-Integration**                         | ✅ Fortgeschritten, automatisch generierte **strenge** Typen & Schlüssel-Autovervollständigung | ✅ Gute Typisierung; **strenge Schlüsselsicherheit erfordert zusätzliche Einrichtung/Disziplinen**         |
+| **Erkennung fehlender Übersetzungen**              | ✅ **Build-Zeit** Warnungen/Fehler und TS-Anzeige                                              | ⚠️ Laufzeit-Fallbacks/Warnungen                                                                            |
+| **Reicher Inhalt (Komponenten/Markdown)**          | ✅ Direkte Unterstützung für reichhaltige Knoten und Markdown-Inhaltsdateien                   | ⚠️ Eingeschränkt (Komponenten über `<i18n-t>`, Markdown über externe Plugins)                              |
+| **KI-gestützte Übersetzung**                       | ✅ Eingebaute Workflows mit eigenen KI-Anbieterschlüsseln                                      | ❌ Nicht eingebaut                                                                                         |
+| **Visueller Editor / CMS**                         | ✅ Kostenloser visueller Editor & optionales CMS                                               | ❌ Nicht eingebaut (externe Plattformen verwenden)                                                         |
+| **Lokalisierte Routenführung**                     | ✅ Helfer für Vue Router/Nuxt zur Generierung lokalisierter Pfade, URLs und `hreflang`         | ⚠️ Nicht im Kern enthalten (verwenden Sie Nuxt i18n oder eine benutzerdefinierte Vue Router-Konfiguration) |
+| **Dynamische Routen-Generierung**                  | ✅ Ja                                                                                          | ❌ Nicht bereitgestellt (wird von Nuxt i18n bereitgestellt)                                                |
+| **Pluralisierung & Formatierung**                  | ✅ Aufzählungsmuster; Intl-basierte Formatierer                                                | ✅ ICU-Stil Nachrichten; Intl Formatierer                                                                  |
+| **Inhaltsformate**                                 | ✅ `.ts`, `.js`, `.json`, `.md`, `.txt` (YAML in Arbeit)                                       | ✅ `.json`, `.js` (plus SFC `<i18n>`-Blöcke)                                                               |
+| **ICU-Unterstützung**                              | ⚠️ In Arbeit                                                                                   | ✅ Ja                                                                                                      |
+| **SEO-Helfer (Sitemap, Robots, Metadaten)**        | ✅ Eingebaute Helfer (framework-unabhängig)                                                    | ❌ Nicht im Kern enthalten (Nuxt i18n/Gemeinschaft)                                                        |
+| **SSR/SSG**                                        | ✅ Funktioniert mit Vue SSR und Nuxt; blockiert kein statisches Rendering                      | ✅ Funktioniert mit Vue SSR/Nuxt                                                                           |
+| **Tree-shaking (nur genutzte Inhalte ausliefern)** | ✅ Pro Komponente zur Build-Zeit                                                               | ⚠️ Teilweise; erfordert manuelles Code-Splitting/async Nachrichten                                         |
+| **Lazy Loading**                                   | ✅ Pro Locale / pro Wörterbuch                                                                 | ✅ Async Locale-Nachrichten werden unterstützt                                                             |
+| **Unbenutzte Inhalte entfernen**                   | ✅ Ja (zur Build-Zeit)                                                                         | ❌ Nicht integriert                                                                                        |
+| **Wartbarkeit bei großen Projekten**               | ✅ Fördert modulare, designsystemfreundliche Struktur                                          | ✅ Möglich, erfordert jedoch strenge Datei-/Namespace-Disziplin                                            |
+| **Ökosystem / Community**                          | ⚠️ Kleiner, aber schnell wachsend                                                              | ✅ Groß und ausgereift im Vue-Ökosystem                                                                    |
+
+---
+
+## Tiefgehender Vergleich
+
+### 1) Architektur & Skalierbarkeit
+
+- **vue-i18n**: Übliche Setups verwenden **zentralisierte Kataloge** pro Locale (optional aufgeteilt in Dateien/Namespaces). SFC-`<i18n>`-Blöcke erlauben lokale Nachrichten, aber Teams greifen oft auf gemeinsame Kataloge zurück, wenn Projekte wachsen.
+- **Intlayer**: Fördert **pro-Komponenten-Wörterbücher**, die neben der jeweiligen Komponente gespeichert werden. Dies reduziert Konflikte zwischen Teams, hält Inhalte auffindbar und begrenzt natürlich Drift/ungenutzte Schlüssel.
+
+**Warum das wichtig ist:** In großen Vue-Anwendungen oder Designsystemen skaliert **modularer Inhalt** besser als monolithische Kataloge.
+
+---
+
+### 2) TypeScript & Sicherheit
+
+- **vue-i18n**: Gute TS-Unterstützung; **strikte Schlüsseltypisierung** erfordert typischerweise benutzerdefinierte Schemata/Generics und sorgfältige Konventionen.
+- **Intlayer**: **Erzeugt strenge Typen** aus deinen Inhalten, bietet **IDE-Autovervollständigung** und **Kompilierzeit-Fehler** bei Tippfehlern oder fehlenden Schlüsseln.
+
+**Warum das wichtig ist:** Starke Typisierung erkennt Probleme **vor** der Laufzeit.
+
+---
+
+### 3) Umgang mit fehlenden Übersetzungen
+
+- **vue-i18n**: **Laufzeit**-Warnungen/Fallbacks (z.B. Rückfall auf Locale oder Schlüssel).
+- **Intlayer**: **Buildzeit**-Erkennung mit Warnungen/Fehlern über alle Locales und Schlüssel hinweg.
+
+**Warum das wichtig ist:** Durchsetzung zur Buildzeit hält die Produktions-UI sauber und konsistent.
+
+---
+
+### 4) Routing- & URL-Strategie (Vue Router/Nuxt)
+
+- **Beide** können mit lokalisierten Routen arbeiten.
+- **Intlayer** bietet Hilfsmittel, um **lokalisierte Pfade zu generieren**, **Locale-Präfixe zu verwalten** und **`<link rel="alternate" hreflang>`** für SEO auszugeben. In Kombination mit Nuxt ergänzt es das Routing des Frameworks.
+
+**Warum das wichtig ist:** Weniger individuelle Verbindungs-Schichten und **saubereres SEO** über verschiedene Sprachen hinweg.
+
+---
+
+### 5) Leistung & Ladeverhalten
+
+- **vue-i18n**: Unterstützt asynchrone Locale-Nachrichten; das Vermeiden von Über-Bundling liegt bei dir (Kataloge sorgfältig aufteilen).
+- **Intlayer**: **Tree-shaking** zur Build-Zeit und **Lazy-Loading pro Wörterbuch/Locale**. Unbenutzte Inhalte werden nicht ausgeliefert.
+
+**Warum das wichtig ist:** Kleinere Bundles und schnellerer Start für mehrsprachige Vue-Anwendungen.
+
+---
+
+### 6) Entwicklererfahrung & Werkzeuge
+
+- **vue-i18n**: Ausgereifte Dokumentation und Community; in der Regel verlassen Sie sich auf **externe Lokalisierungsplattformen** für redaktionelle Workflows.
+- **Intlayer**: Bietet einen **kostenlosen visuellen Editor**, ein optionales **CMS** (Git-freundlich oder externalisiert), eine **VSCode-Erweiterung**, **CLI/CI**-Werkzeuge und **KI-unterstützte Übersetzungen** mit Ihren eigenen Anbieter-Schlüsseln.
+
+**Warum das wichtig ist:** Geringere Betriebskosten und eine kürzere Entwicklungs-Content-Schleife.
+
+---
+
+### 7) SEO, SSR & SSG
+
+- **Beide** funktionieren mit Vue SSR und Nuxt.
+- **Intlayer**: Fügt **SEO-Hilfsmittel** hinzu (Sitemaps/Metadaten/`hreflang`), die frameworkunabhängig sind und gut mit Vue/Nuxt-Builds zusammenarbeiten.
+
+**Warum das wichtig ist:** Internationale SEO ohne maßgeschneiderte Verkabelung.
+
+---
+
+## Warum Intlayer? (Problem & Ansatz)
+
+Die meisten i18n-Stacks (einschließlich **vue-i18n**) starten mit **zentralisierten Katalogen**:
+
+```bash
+.
+├── locales
+│   ├── en.json
+│   ├── es.json
+│   └── fr.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+Oder mit pro-Locale-Ordnern:
+
+```bash
+.
+├── locales
+│   ├── en
+│   │  ├── footer.json
+│   │  └── navbar.json
+│   ├── fr
+│   │  ├── footer.json
+│   │  └── navbar.json
+│   └── es
+│      ├── footer.json
+│      └── navbar.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+Dies verlangsamt die Entwicklung oft, wenn Anwendungen wachsen:
+
+1. **Für eine neue Komponente** erstellen/bearbeiten Sie entfernte Kataloge, verbinden Namespaces und übersetzen (oft durch manuelles Kopieren/Einfügen aus KI-Tools).
+2. **Beim Ändern von Komponenten** suchen Sie gemeinsam genutzte Schlüssel, übersetzen, halten die Lokalisierungen synchron, entfernen veraltete Schlüssel und gleichen JSON-Strukturen an.
+
+**Intlayer** grenzt Inhalte **pro Komponente** ab und hält sie **neben dem Code**, so wie wir es bereits mit CSS, Stories, Tests und Dokumentationen tun:
+
+```bash
+.
+└── components
+    └── MyComponent
+        ├── MyComponent.content.ts
+        └── MyComponent.vue
+```
+
+**Inhaltsdeklaration** (pro Komponente):
+
+```ts fileName="./components/MyComponent/MyComponent.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+const componentExampleContent = {
+  key: "component-example",
+  content: {
+    greeting: t({
+      en: "Hello World",
+      es: "Hola Mundo",
+      fr: "Bonjour le monde",
+    }),
+  },
+} satisfies Dictionary;
+
+export default componentExampleContent;
+```
+
+**Verwendung in Vue** (Composition API):
+
+```vue fileName="./components/MyComponent/MyComponent.vue"
+<script setup lang="ts">
+import { useIntlayer } from "vue-intlayer"; // Vue-Integration
+const { greeting } = useIntlayer("component-example");
+</script>
+
+<template>
+  <span>{{ greeting }}</span>
+</template>
+```
+
+Dieser Ansatz:
+
+- **Beschleunigt die Entwicklung** (einmal deklarieren; IDE/AI vervollständigt automatisch).
+- **Bereinigt den Codebestand** (1 Komponente = 1 Wörterbuch).
+- **Erleichtert Duplikation/Migration** (kopiere eine Komponente und deren Inhalt zusammen).
+- **Vermeidet tote Schlüssel** (ungenutzte Komponenten importieren keinen Inhalt).
+- **Optimiert das Laden** (lazy-geladene Komponenten bringen ihren Inhalt mit).
+
+---
+
+## Zusätzliche Funktionen von Intlayer (Vue-relevant)
+
+- **Framework-übergreifende Unterstützung**: Funktioniert mit Vue, Nuxt, Vite, React, Express und mehr.
+- **JavaScript-gesteuertes Content-Management**: Deklaration im Code mit voller Flexibilität.
+- **Pro-Locale-Deklarationsdatei**: Säen Sie alle Sprachen und lassen Sie die Tools den Rest generieren.
+- **Typensicheres Umfeld**: Starke TS-Konfiguration mit Autovervollständigung.
+- **Vereinfachte Inhaltsabfrage**: Ein einziger Hook/Composable, um alle Inhalte für ein Wörterbuch abzurufen.
+- **Organisierter Codebasis**: 1 Komponente = 1 Wörterbuch im selben Ordner.
+- **Erweiterte Routing-Funktionen**: Helfer für **Vue Router/Nuxt** lokalisierte Pfade und Metadaten.
+- **Markdown-Unterstützung**: Importieren Sie remote/lokales Markdown pro Sprache; stellen Sie Frontmatter dem Code zur Verfügung.
+- **Kostenloser visueller Editor & optionales CMS**: Erstellung ohne kostenpflichtige Lokalisierungsplattform; Git-freundliche Synchronisation.
+- **Tree-shakable Inhalte**: Liefert nur das, was verwendet wird; unterstützt Lazy Loading.
+- **SSG-freundlich**: Blockiert das statische Rendering nicht.
+- **KI-gestützte Übersetzungen**: Übersetzen Sie in 231 Sprachen mit Ihrem eigenen KI-Anbieter/API-Schlüssel.
+- **MCP-Server & VSCode-Erweiterung**: Automatisieren Sie i18n-Workflows und das Verfassen direkt in Ihrer IDE.
+- **Interoperabilität**: Verbindet bei Bedarf mit **vue-i18n**, **react-i18next** und **react-intl**.
+
+---
+
+## Wann welches wählen?
+
+- **Wählen Sie vue-i18n**, wenn Sie den **standardmäßigen Vue-Ansatz** bevorzugen, gerne selbst Kataloge/Namespaces verwalten und Ihre App **klein bis mittelgroß** ist (oder Sie bereits Nuxt i18n verwenden).
+- **Wählen Sie Intlayer**, wenn Sie **komponentenbezogenen Inhalt**, **striktes TypeScript**, **Build-Zeit-Garantien**, **Tree-Shaking** und **umfangreiche Routing/SEO/Editor-Tools** schätzen – besonders für **große, modulare Vue/Nuxt-Codebasen**.
+
+---
+
+## Praktische Migrationshinweise (vue-i18n → Intlayer)
+
+- **Pro Funktion starten**: Verschieben Sie eine Route/Ansicht/Komponente nach der anderen in lokale Intlayer-Wörterbücher.
+- **Brücke während der Migration**: Behalten Sie die vue-i18n-Kataloge parallel bei; ersetzen Sie die Abfragen schrittweise.
+- **Strenge Prüfungen aktivieren**: Lassen Sie fehlende Schlüssel/Locales frühzeitig zur Build-Zeit erkennen.
+- **Router/SEO-Hilfen übernehmen**: Standardisieren Sie die Lokalerkennung und `hreflang`-Tags.
+- **Bundles messen**: Erwarten Sie **Reduzierungen der Bundle-Größe**, da ungenutzte Inhalte ausgeschlossen werden.
+
+---
+
+## Fazit
+
+Sowohl **vue-i18n** als auch **Intlayer** lokalisieren Vue-Apps gut. Der Unterschied liegt darin, **wie viel Sie selbst aufbauen müssen**, um eine robuste, skalierbare Lösung zu erreichen:
+
+- Mit **Intlayer** sind **modularer Inhalt**, **striktes TypeScript**, **Build-Zeit-Sicherheit**, **baumgeschüttelte Bundles** sowie **Router-/SEO-/Editor-Tools** **standardmäßig enthalten**.
+- Wenn Ihr Team **Wartbarkeit und Geschwindigkeit** in einer mehrsprachigen, komponentenbasierten Vue/Nuxt-Anwendung priorisiert, bietet Intlayer heute die **vollständigste** Erfahrung.
+
+Siehe das Dokument ['Warum Intlayer?'](https://intlayer.org/doc/why) für weitere Details.

package/blog/en/intlayer_with_next-i18next.md

@@ -1,6 +1,6 @@
 ---
-createdAt: 2024-08-11
-updatedAt: 2025-06-29
+createdAt: 2025-08-23
+updatedAt: 2025-08-23
 title: Intlayer and next-i18next
 description: Integrate Intlayer with next-i18next for a Next.js app
 keywords: