Inhaltsverzeichnis
CMS-Lokalisierung: Mehrsprachige Inhalte in großem Maßstab verwalten
Wichtigste Erkenntnisse
- Die Wahl der CMS-Lokalisierungsarchitektur (Feldebene, Eintragsebene oder separate Content-Trees) wirkt sich erheblich auf den redaktionellen Workflow und die Skalierbarkeit aus
- Headless-CMS-Plattformen mit integrierter i18n-Unterstützung bieten die flexibelste mehrsprachige Content-Verwaltung
- Content-Modellierung muss lokalisierungsspezifische Felder, gemeinsame Assets und die Nachverfolgung des Übersetzungsstatus berücksichtigen
- Redaktionelle Workflows sollten Übersetzungszuweisung, Review und Publikationsstufen pro Locale umfassen
CMS-Lokalisierungsarchitektur
Ansatz 1: Feldebenen-Lokalisierung
Jedes Inhaltsfeld speichert Werte für alle Locales:
{
"title": {
"en": "Getting Started Guide",
"de": "Erste-Schritte-Anleitung",
"fr": "Guide de démarrage"
},
"body": {
"en": "Welcome to...",
"de": "Willkommen bei...",
"fr": "Bienvenue sur..."
}
}
Vorteile: Ein einziger Content-Eintrag pro Inhalt, einfache Übersicht des Übersetzungsstatus. Nachteile: Komplexes Content-Modell, alle Locales werden geladen, auch wenn nur eine benötigt wird.
Ansatz 2: Eintragsebenen-Lokalisierung
Separate Content-Einträge für jedes Locale, verknüpft durch eine Referenz:
// Englischer Eintrag
{ "id": "guide-en", "locale": "en", "ref": "guide", "title": "Getting Started" }
// Deutscher Eintrag
{ "id": "guide-de", "locale": "de", "ref": "guide", "title": "Erste Schritte" }
Vorteile: Saubere Trennung, nur benötigtes Locale laden, unabhängige Veröffentlichung. Nachteile: Mehr Einträge zu verwalten, Übersetzungslücken schwerer zu erkennen.
Ansatz 3: Separate Content-Trees
Jedes Locale hat seinen eigenen vollständigen Content-Tree und ermöglicht vollständig unabhängige Content-Strategien pro Markt.
Vorteile: Maximale Flexibilität, Märkte können einzigartige Inhalte haben. Nachteile: Höchster Verwaltungsaufwand, schwierig Inhalte synchron zu halten.
Headless CMS für mehrsprachige Inhalte
Headless-CMS-Plattformen trennen Inhalt von der Präsentation und eignen sich daher gut für mehrsprachige Auslieferung:
| Funktion | Warum es für i18n wichtig ist |
|---|---|
| API-first-Auslieferung | Locale-spezifische Inhalte an jedes Frontend liefern |
| Flexibles Content-Modell | Definieren, welche Felder lokalisierbar sind |
| Webhook-Unterstützung | Builds auslösen, wenn Übersetzungen veröffentlicht werden |
| Rollenbasierter Zugriff | Übersetzer bestimmten Locales zuweisen |
| Publikations-Workflow | Review und Veröffentlichung pro Locale unabhängig |
Content-Modellierung für die Lokalisierung
Lokalisierbare vs. nicht lokalisierbare Felder
Nicht alle Inhaltsfelder müssen übersetzt werden:
| Lokalisierbar | Nicht lokalisierbar |
|---|---|
| Titel, Body, Excerpt | Slug (meistens), Erstellungsdatum |
| Meta-Titel, Meta-Beschreibung | Autorreferenz, Kategorie |
| Alt-Text für Bilder | Featured-Image-URL (meistens) |
| CTA-Text | Interne Tags, Sortierreihenfolge |
Gemeinsame Assets
Bilder und Mediendateien müssen möglicherweise lokalisiert werden:
- Global geteilt: Produktfotos, Logos, Icons
- Locale-spezifisch: Screenshots mit UI-Text, Infografiken mit Daten, Marketing-Banner
- Teilweise lokalisiert: Videos (gemeinsame Bilder, lokalisierte Untertitel/Audio)
Redaktioneller Workflow für mehrsprachiges CMS
Workflow-Stufen pro Locale
- Quellinhalt erstellt — Autor schreibt in der Quellsprache
- Übersetzung zugewiesen — Neue Inhalte werden zur Übersetzung markiert
- In Übersetzung — Übersetzer arbeitet am Inhalt
- Review — Redakteur überprüft übersetzten Inhalt auf Genauigkeit und Ton
- Veröffentlicht — Locale-spezifischer Inhalt geht live
- Aktualisiert — Änderungen am Quellinhalt lösen erneuten Übersetzungs-Workflow aus
Übersetzungsstatus verwalten
Übersetzungsstatus pro Eintrag und pro Locale verfolgen:
| Eintrag | EN | DE | FR | JA |
|---|---|---|---|---|
| Getting Started | Veröffentlicht | In Review | In Übersetzung | Nicht gestartet |
| Pricing | Veröffentlicht | Veröffentlicht | Veröffentlicht | In Übersetzung |
| Blog Post #42 | Veröffentlicht | Nicht gestartet | Nicht gestartet | Nicht gestartet |
FAQ
Welche CMS-Architektur ist am besten für die Lokalisierung geeignet? Feldebenen-Lokalisierung eignet sich gut für kleine bis mittlere Websites mit konsistenten Inhalten über Locales hinweg. Eintragsebenen-Lokalisierung ist besser für große Websites oder wenn sich Inhalte erheblich je nach Markt unterscheiden.
Sollte ich ein dediziertes TMS neben meinem CMS verwenden? Für einfache mehrsprachige Websites kann die integrierte CMS-Lokalisierung ausreichen. Für komplexe Workflows mit professionellen Übersetzern bietet ein dediziertes TMS, das mit Ihrem CMS integriert ist, eine bessere Übersetzer-Erfahrung und Translation-Memory-Unterstützung.
Wie gehe ich mit SEO für lokalisierte CMS-Inhalte um? Generieren Sie locale-spezifische URLs, Meta-Tags und hreflang-Tags aus CMS-Daten. Stellen Sie sicher, dass jede Locale-Version einzigartige, optimierte Metadaten hat — nicht nur übersetzte Versionen.
Kann ich erste Übersetzungen im CMS automatisieren? Viele CMS-Plattformen unterstützen MT-Integration zur Generierung erster Entwürfe. Diese Entwürfe sollten immer von menschlichen Redakteuren vor der Veröffentlichung geprüft werden.
Wie gehe ich mit Inhalten um, die nicht übersetzt werden sollen? Markieren Sie bestimmte Einträge oder Felder als „nicht übersetzen" in Ihrem Content-Modell. Verwenden Sie locale-spezifische Veröffentlichung, um zu steuern, welche Inhalte in welchen Märkten erscheinen.
