Tutorials//9 Min. Lesezeit

Der vollständige Leitfaden zum Aufbau einer mehrsprachigen Headless CMS Strategie

Eray Gündoğmuş
Teilen

Inhalte in einer Sprache zu verwalten ist bereits eine Herausforderung. Fügen Sie drei, fünf oder zwanzig Sprachen hinzu, und Sie stehen vor einem Problem, das die meisten CMS-Plattformen nie dafür ausgelegt waren zu lösen. Headless CMS Architektur bietet einen Weg nach vorne – aber nur, wenn die mehrsprachige Unterstützung von Grund auf in das Fundament integriert ist und nicht nachträglich als Plugin hinzugefügt wird.

Dieser Leitfaden zeigt, wie Sie eine skalierbare mehrsprachige Headless CMS Strategie aufbauen, und verwendet dabei Better i18n's Content-Plattform als praktisches Referenzbeispiel.

Was macht ein CMS "mehrsprachig-bereit"?

Bevor wir in die Implementierung eintauchen, ist es hilfreich zu definieren, wie echte mehrsprachige Unterstützung aussieht. Ein CMS ist mehrsprachig-bereit, wenn es drei Anforderungen erfüllt:

  1. Die Content-Struktur ist sprachbewusst. Das Schema unterscheidet zwischen Feldern, die übersetzt werden müssen (Titel, Beschreibungen, Fließtext), und Feldern, die universell sind (Datumsangaben, Boolean-Werte, numerische Werte, Medien-Assets).

  2. Die API liefert lokalisierten Content nativ aus. Sie können Content in beliebiger Sprache mit einem Query-Parameter abrufen – ohne separate Content-Bäume zu pflegen oder Einträge pro Locale zu duplizieren.

  3. Der Übersetzungsstatus ist sichtbar. Redakteure können sehen, welche Einträge übersetzt wurden, welche ausstehen und welche für eine bestimmte Sprache fehlen – ohne das CMS-Dashboard verlassen zu müssen.

Wenn Ihr aktuelles CMS benutzerdefinierten Code oder Drittanbieter-Services benötigt, um eines dieser drei Kriterien zu erfüllen, bauen Sie auf einem Fundament auf, das bei zunehmendem Wachstum Reibung erzeugen wird.

Schritt 1: Entwerfen Sie Ihre Content-Modelle

Ein Content-Modell ist das Schema, das definiert, wie Ihr Content aussieht. Betrachten Sie es als Blueprint – es legt die Felder, deren Typen und Validierungsregeln fest.

Collections vs. Singletons

Der meiste Content fällt in zwei Kategorien:

  • Collections sind Modelle mit mehreren Einträgen. Blog-Posts, Produktseiten, FAQs, Team-Profile und Changelog-Einträge sind allesamt Collections. Jede Collection kann Hunderte oder Tausende von Einträgen haben, die dieselbe Feldstruktur teilen.

  • Singletons sind Modelle mit einem einzigen Eintrag. Ihr Homepage-Hero-Bereich, globale Website-Einstellungen oder eine "Über uns"-Seite sind Singletons. Sie haben dieselbe Feldflexibilität wie Collections, repräsentieren aber nur eine einzelne Instanz.

Mit dem richtigen Modelltyp zu beginnen spart spätere Überarbeitungen. Fragen Sie sich: "Wird es davon jemals mehr als eines geben?" Wenn ja, verwenden Sie eine Collection.

Die richtigen Feldtypen wählen

Better i18n bietet mehr als 19 Feldtypen, damit Sie Content präzise modellieren können, ohne auf Workarounds wie das Speichern strukturierter Daten in einem Textarea-Feld zurückgreifen zu müssen.

Hier ist eine praktische Übersicht nach Kategorie:

Textfelder:

  • Text — Einzeilige Strings für Titel, Labels und kurze Werte
  • Textarea — Mehrzeiliger Klartext für Beschreibungen und Zusammenfassungen
  • Rich Text — Ein vollständiger Plate.js-Editor für formatierten Content mit Überschriften, Listen, Einbettungen und Inline-Stilen

Datenfelder:

  • Number — Ganzzahl- oder Dezimalwerte (Preise, Mengen, Bewertungen)
  • Boolean — Wahr/Falsch-Umschalter (Featured-Flags, Sichtbarkeitssteuerung)
  • Date / DateTime — Datumsauswahl mit optionaler Zeitpräzision
  • Enum — Einzel- oder Mehrfachauswahl aus vordefinierten Optionen (Kategorien, Tags, Status-Labels)

Kontakt- und Linkfelder:

  • URL — Validierte URL-Felder für Links und Referenzen
  • Email — Validierte E-Mail-Adressfelder
  • Phone — Telefonnummernfelder mit Formatvalidierung

Medien und Dateien:

  • Files / Media — Bilder, PDFs, Videos und andere Assets direkt in Einträge hochladen

Relationale Felder:

  • Relations — Einträge modellübergreifend verknüpfen (z. B. Autor eines Blog-Posts, Kategorie eines Produkts)
  • Rollups — Daten aus verwandten Einträgen aggregieren (z. B. Anzahl der Posts pro Autor)
  • Formulas — Berechnete Werte basierend auf anderen Feldern im selben Eintrag

Systemfelder:

  • Unique ID — Automatisch generierter Bezeichner für jeden Eintrag
  • Status — Integrierter Workflow-Zustand (draft, pending_review, published, archived)
  • Created / Last Edited — Automatische Zeitstempel für Audit-Trails

Feldbasierte Lokalisierung

Hier wird das mehrsprachige CMS-Design interessant. Nicht jedes Feld muss übersetzt werden. Der Preis eines Produkts ist in jeder Sprache gleich. Ein Veröffentlichungsdatum ändert sich nicht je nach Locale. Eine Bild-URL ist in der Regel universell.

Better i18n ermöglicht es Ihnen, jedes Feld auf Modellebene als lokalisierbar oder nicht-lokalisierbar zu markieren. Lokalisierbare Felder erhalten pro Sprache einen separaten Wert. Nicht-lokalisierbare Felder werden über alle Übersetzungen hinweg geteilt.

Diese Unterscheidung ist wichtig, weil sie:

  • Den Übersetzungsaufwand reduziert (Übersetzer sehen nur die Felder, die sie übersetzen müssen)
  • Dateninkonsistenzen verhindert (universelle Werte werden einmal gespeichert, nicht dupliziert)
  • Die API-Antwort sauber hält (nicht-lokalisierbare Felder erscheinen einmal, unabhängig von der angeforderten Sprache)

Schritt 2: Bauen Sie Ihren redaktionellen Workflow auf

Reine CRUD-Operationen reichen für Teams, die mehrsprachigen Content verwalten, nicht aus. Sie benötigen einen Workflow, der Qualität sicherstellt, ohne Engpässe zu erzeugen.

Der Status-Lebenszyklus

Jeder Eintrag in Better i18n folgt einem vierstufigen Lebenszyklus:

StatusBedeutungAPI-Sichtbarkeit
DraftIn BearbeitungStandardmäßig nicht zurückgegeben
Pending ReviewBereit für redaktionelle FreigabeStandardmäßig nicht zurückgegeben
PublishedLive-ContentIn API-Abfragen zurückgegeben
ArchivedGespeichert, aber inaktivStandardmäßig nicht zurückgegeben

Dieser Lebenszyklus gilt pro Eintrag, nicht pro Sprache. Ein Eintrag kann veröffentlicht werden, auch wenn einige Übersetzungen noch im Draft-Status sind. Die API respektiert den status-Query-Parameter, sodass Ihr Frontend nur Content im angeforderten Status erhält.

Massenoperationen für mehr Skalierbarkeit

Wenn Sie Hunderte von Einträgen in mehreren Sprachen verwalten, skalieren Einzelaktualisierungen nicht. Better i18n unterstützt Massenoperationen:

  • Massen-Statusaktualisierungen — Mehrere Einträge auswählen und sie in einer Aktion von Draft auf Published (oder einen anderen Status) verschieben
  • Massenlöschung — Veraltete Einträge in einem Batch entfernen

Diese Operationen sind im Dashboard und über die Management-API verfügbar, sodass Sie sie in Ihre CI/CD-Pipeline oder Content-Automatisierungsskripte integrieren können.

Schritt 3: Integration über die REST API

Der "Headless"-Teil von "Headless CMS" bedeutet, dass Ihr Content über eine API ausgeliefert wird, nicht über ein gekoppeltes Frontend. Better i18n bietet eine öffentliche REST API mit drei zentralen Endpunkten:

Kern-Endpunkte

GET /v1/content/:orgSlug/:projectSlug/models
GET /v1/content/:orgSlug/:projectSlug/entries
GET /v1/content/:orgSlug/:projectSlug/entries/:entrySlug

Wichtige Query-Parameter

Die eigentliche Stärke der API liegt in ihren Query-Parametern:

Sprachfilterung:

GET /entries?language=fr

Gibt den gesamten Content auf Französisch zurück. Als nicht-lokalisierbar markierte Felder geben ihren universellen Wert zurück. Lokalisierbare Felder geben die französische Übersetzung zurück, wenn vorhanden.

Statusfilterung:

GET /entries?status=published

Gibt nur veröffentlichte Einträge zurück. Für Produktionsabfragen mit Sprache kombinieren:

GET /entries?language=de&status=published

Feldauswahl (Sparse Fieldsets):

GET /entries?fields=title,slug,excerpt

Reduzieren Sie die Payload-Größe, indem Sie nur die Felder anfordern, die Ihr Frontend benötigt.

Beziehungserweiterung:

GET /entries?expand=author,category

Verwandte Einträge inline auflösen, anstatt Folgeabfragen zu stellen. Dies beseitigt das N+1-Abfrageproblem, das viele Headless CMS Integrationen plagt.

Filterung nach benutzerdefinierten Feldern:

GET /entries?filter[page_type]=feature

Einträge nach beliebigen benutzerdefinierten Feldwerten filtern. Mehrere Filter für präzise Abfragen kombinieren.

Paginierung und Sortierung:

GET /entries?page=2&limit=10&sort=createdAt&order=desc

Standard-Paginierung mit flexibler Sortierung. Die Antwort enthält die Gesamtanzahl für den Aufbau einer Paginierungs-UI.

Authentifizierung

Alle API-Anfragen erfordern einen API-Schlüssel, der im x-api-key-Header übergeben wird. Sie können mehrere Schlüssel mit unterschiedlichen Berechtigungen erstellen – beispielsweise einen Nur-Lese-Schlüssel für Ihr Frontend und einen Vollzugriff-Schlüssel für Ihre CMS-Integrationsskripte.

curl -H "x-api-key: your-api-key" \
  "https://api.better-i18n.com/v1/content/acme/website/entries?language=en&status=published"

Schritt 4: KI-gestützte Content-Generierung strategisch einsetzen

Better i18n enthält KI-gestützte Content-Generierung auf Feldebene. Die generateFieldContent-Funktion analysiert Ihre Modellstruktur und vorhandenen Inhalte, um Werte für einzelne Felder vorzuschlagen.

Wo KI-Generierung Mehrwert schafft

  • SEO-Meta-Beschreibungen — Beschreibungen basierend auf Titel und Fließtext des Eintrags generieren
  • Auszüge und Zusammenfassungen — Langform-Content in prägnante Vorschauen kondensieren
  • Erste Entwürfe — Einen Ausgangspunkt für Fließtext erhalten, der zur Struktur Ihres Modells passt
  • Alt-Text für Bilder — Beschreibenden Alt-Text basierend auf dem Bildkontext generieren

Wo menschliches Urteil bewahrt werden muss

KI-Generierung ist ein Ausgangspunkt, kein finales Ergebnis. Nutzen Sie sie, um die Leere-Seite-Lähmung zu überwinden, und bearbeiten Sie den Text dann so, dass er zu Ihrer Markenstimme und Ihren sachlichen Anforderungen passt. Der feldbasierte Ansatz gibt Ihnen genaue Kontrolle darüber, welche Felder KI-Vorschläge verwenden und welche manuell verfasst werden.

Schritt 5: Planen Sie Ihre Content-Architektur

Mit den Grundbausteinen an Ort und Stelle ist hier eine praktische Architektur für eine mehrsprachige Website:

Empfohlene Modelle

ModellTypVerwendungszweck
pagesCollectionMarketing-Seiten, Landing Pages
blog-postsCollectionArtikel, Tutorials, Ankündigungen
navigationSingletonWebsite-Navigationsstruktur
site-settingsSingletonGlobale Konfiguration (Logo, Footer, Social-Links)
faqCollectionHäufig gestellte Fragen
changelogCollectionProduktupdates und Release Notes

Übersetzungs-Workflow

  1. Content in Ihrer Quellsprache erstellen. Den Eintrag in der Hauptsprache Ihres Teams verfassen.
  2. Das Übersetzungsstatus-Dashboard nutzen, um Einträge mit fehlenden Übersetzungen zu identifizieren.
  3. Übersetzungen feldweise hinzufügen über den Eintragseditor oder die API.
  4. Bei Bereitschaft veröffentlichen — der Status-Lebenszyklus erlaubt es Ihnen, die Quellsprache sofort zu veröffentlichen und Übersetzungen hinzuzufügen, sobald sie verfügbar sind.

Häufige Fallstricke vermeiden

Einträge pro Sprache duplizieren. Dies ist der häufigste Fehler. Wenn Sie separate Einträge für englische, französische und deutsche Versionen derselben Seite erstellen, verlieren Sie die Verbindung zwischen ihnen. Verwenden Sie stattdessen einen einzigen Eintrag mit feldbasierten Übersetzungen.

Nicht-lokalisierbare Felder ignorieren. Universelle Felder (Preise, Datumsangaben, Boolean-Flags) nicht als nicht-lokalisierbar zu markieren bedeutet, dass Übersetzer Felder sehen, die sie nicht anfassen sollten, und Sie riskieren Dateninkonsistenzen.

Den Status-Workflow überspringen. Content ohne Überprüfungsphasen direkt zu veröffentlichen funktioniert für einen Solo-Blogger, scheitert aber in Teams. Nutzen Sie den Draft-zu-Published-Lebenszyklus, um Qualität zu sichern.

Zu viele Daten von der API abrufen. Verwenden Sie den fields-Parameter, um nur das anzufordern, was Ihr Frontend benötigt. Nutzen Sie expand, um Beziehungen in einer einzigen Anfrage aufzulösen, anstatt mehrere API-Aufrufe zu verketten.

Erste Schritte

Eine mehrsprachige Content-Strategie aufzubauen erfordert keine monatelange Infrastrukturarbeit. Mit Better i18n's Headless CMS:

  1. Definieren Sie Ihre Content-Modelle im Model Builder
  2. Erstellen Sie Einträge in Ihrer Quellsprache
  3. Fügen Sie Übersetzungen über den Eintragseditor oder die API hinzu
  4. Fragen Sie lokalisierten Content über die REST API ab
  5. Nutzen Sie KI-Generierung, um die Content-Erstellung zu beschleunigen

Der gesamte Workflow — von der Modellerstellung bis zur API-Auslieferung — ist für Teams konzipiert, die mehrsprachigen Content als zentralen Bestandteil ihres Produkts liefern, nicht als nachträgliche Ergänzung.

Headless CMS Dokumentation erkunden →

Comments

Loading comments...