Blog

Umfassender Leitfaden zur mehrsprachigen Übersetzung von WordPress-Websites

Leonardo Losoviz
Von Leonardo Losoviz ·

Die Übersetzung einer WordPress-Website ist ein komplexer Prozess, der sorgfältige Planung und Ausführung erfordert. Wir haben diesen umfassenden Leitfaden auf Basis unserer umfangreichen Erfahrung bei der Übersetzung von Websites erstellt, unter Verwendung des Plugins Gato AI Translations for Polylang.

Dieser Leitfaden führt dich durch alles, was du wissen musst: von den ersten Vorbereitungen und der Konfiguration über den eigentlichen Übersetzungsprozess bis hin zur Validierung und Fehlerbehebung. Folge diesem Leitfaden, um eine reibungslose Übersetzungserfahrung zu gewährleisten.

Polylang installieren und konfigurieren

Gato AI Translations for Polylang erfordert, dass Polylang installiert und aktiviert ist. Polylang ist das mehrsprachige Framework, das deine Sprachen und Übersetzungsbeziehungen verwaltet.

Nach der Installation musst du Polylang konfigurieren mit deinen Sprachen:

  1. Gehe zu Languages im WordPress-Administrationsmenü
  2. Füge deine Standardsprache hinzu (die Sprache deines vorhandenen Inhalts)
  3. Füge alle Zielsprachen hinzu, in die du übersetzen möchtest
Polylang-Sprachen konfigurieren
Sprachen in den Polylang-Einstellungen hinzufügen und konfigurieren

Du musst sicherstellen, dass alle deine aktiven Plugins mit Polylang kompatibel sind. Einige Plugins funktionieren in einer mehrsprachigen Umgebung möglicherweise nicht korrekt.

Wenn du ein inkompatibles Plugin entdeckst, suche nach Alternativen, kontaktiere den Entwickler für Support oder überlege, ob es wirklich unverzichtbar ist.

Ursprungsinhalt zuerst prüfen und korrigieren

Bevor du mit der Übersetzung beginnst, ist es wichtig sicherzustellen, dass dein Ursprungsinhalt in einwandfreiem Zustand ist. Alle Probleme in deinem Originalinhalt werden in alle Übersetzungen übernommen, was bedeutet, dass du dasselbe Problem mehrmals beheben musst (einmal pro Sprache).

Checkliste für die Inhaltsüberprüfung:

  1. Auf fehlerhafte Links prüfen

    • Verwende ein Plugin wie Broken Link Checker, um fehlerhafte interne und externe Links zu identifizieren
    • Behebe alle fehlerhaften Links vor der Übersetzung
    • Stelle sicher, dass interne Links auf die richtigen Beiträge/Seiten zeigen
  2. Prüfen, ob alle Bilder vorhanden und optimiert sind

    • Prüfe, ob alle Bilder korrekt geladen werden
    • Stelle sicher, dass Bilder einen geeigneten Alt-Text für Barrierefreiheit und SEO haben
    • Überprüfe, ob die Bilddateigrößen angemessen sind (nicht zu groß)
    • Entferne Platzhalterbilder oder fehlerhafte Bildreferenzen
  3. Formatierung und Stil überprüfen

    • Prüfe, ob die Textformatierung konsistent ist
    • Stelle sicher, dass Überschriften korrekt strukturiert sind (H1, H2, H3 usw.)
    • Stelle sicher, dass Listen, Tabellen und andere strukturierte Inhalte korrekt angezeigt werden
    • Prüfe, ob benutzerdefinierte Stile und CSS wie erwartet funktionieren
  4. Inhaltsstruktur validieren

    • Stelle sicher, dass Gutenberg-Blöcke oder Page-Builder-Elemente korrekt verwendet werden
    • Prüfe, ob benutzerdefinierte Beitragstypen und Taxonomien korrekt eingerichtet sind
    • Stelle sicher, dass Metadaten (benutzerdefinierte Felder, ACF-Felder usw.) vollständig sind
  5. Auf Platzhalterinhalt prüfen

    • Entferne jeglichen "Lorem ipsum"- oder Platzhaltertext
    • Ersetze temporäre Inhalte durch endgültige Versionen
    • Stelle sicher, dass alle Inhalte veröffentlichungsbereit sind
  6. SEO-Überlegungen

    • Stelle sicher, dass Meta-Titel und Beschreibungen gesetzt sind
    • Prüfe, ob URLs SEO-freundlich sind
    • Stelle die korrekte Verwendung von Überschriften für die SEO-Struktur sicher

Bei der Übersetzung von Inhalten müssen interne Links aktualisiert werden, um auf die übersetzten Versionen zu zeigen. Gato AI Translations for Polylang kann das automatisch für dich erledigen.

Das Plugin ermöglicht dir zu konfigurieren, welche Arten von internen Links ersetzt werden sollen:

  • Custom Posts: Links zu anderen Beiträgen, Seiten, benutzerdefinierten Beitragstypen usw.
  • Media: Links zu Medienelementen (Bilder, Videos usw.)
  • Tags: Links zu Tag-Archivseiten
  • Categories: Links zu Kategoriearchivseiten
  • Users: Links zu Autorenseiten

Beitragslinks im Inhalt werden automatisch aus dem Ursprungsinhalt extrahiert und ersetzt. Für andere Linktypen (Medien, Tags, Kategorien, Benutzer) musst du sie in den Einstellungen aktivieren, wenn sie ersetzt werden sollen.

Vorgehensweise zur Konfiguration:

  1. Gehe zur Einstellungsseite unter Plugin Configuration > Internal Links Replacement
  2. Aktiviere nur die Linktypen, die du tatsächlich in deinem Inhalt verwendest
  3. Speichere deine Einstellungen
Einstellungsseite zum Ersetzen interner Links
Konfiguriere, welche Arten von internen Links in den Plugin-Einstellungen ersetzt werden sollen

Damit die Funktion zur Ersetzung interner Links korrekt funktioniert, müssen alle Links in deinem Inhalt das richtige URL-Format verwenden. Dies gilt für Links in:

  • Beitrags-/Seiteninhalt (Gutenberg-Blöcke, HTML usw.)
  • Elementor-Widgets und Meta-Felder
  • Bricks-Builder-Elemente und Meta-Felder
  • Benutzerdefinierte Felder und Metadaten

URL-Anforderungen:

  1. URLs müssen die vollständige Domain enthalten

    • ✅ Korrekt: https://www.mysite.com/hello-world/
    • ❌ Falsch: /hello-world/ (relative URL)
    • ❌ Falsch: hello-world/ (keine Domain oder Protokoll)
  2. URLs müssen auf den aktuellen Slug zeigen

    • Wenn du den Slug eines Beitrags geändert hast, aktualisiere alle Links, um den neuen Slug zu verwenden
    • WordPress muss in der Lage sein, den Beitrag über die URL abzurufen
    • Alte Slugs mit Weiterleitungen funktionieren nicht für die Link-Ersetzung
  3. URLs müssen die korrekte Domain verwenden (keine Weiterleitungen)

    • ✅ Korrekt: https://www.mysite.com/hello-world/
    • ❌ Falsch: https://mysite.com/hello-world/ (wenn deine Website www verwendet)
    • Das Plugin benötigt die exakte Domain, um Links korrekt abzugleichen und zu ersetzen

Um falsche Domains in URLs zu korrigieren, kannst du ein Plugin wie Better Search Replace verwenden, um URLs direkt in deiner Datenbank zu suchen und zu ersetzen, z. B.: Ersetzen von https://mysite.com durch https://www.mysite.com.

Entwurfs- oder Veröffentlichungsstatus wählen

Wenn Übersetzungen erstellt werden, musst du entscheiden, ob sie sofort veröffentlicht oder zunächst als Entwürfe zur Überprüfung gespeichert werden sollen.

Standardmäßig werden Übersetzungen als Entwürfe gespeichert. Damit Übersetzungen sofort veröffentlicht werden, gehe zur Einstellungsseite unter Plugin Configuration > General Configuration und stelle die Option Status when translated auf Publish oder Same as origin post (wenn der Ursprungsbeitrag bereits veröffentlicht ist).

Die Option 'Status when translated' auf 'Publish' oder 'Same as origin post' einstellen
Die Option 'Status when translated' auf 'Publish' oder 'Same as origin post' einstellen

Wenn du in Rechts-nach-Links-Sprachen wie Hebräisch, Arabisch, Farsi oder Urdu übersetzt, musst du sicherstellen, dass dein Theme RTL-Layouts korrekt unterstützt.

Blocksy-Theme mit LTR-Layout
Blocksy-Theme mit RTL-Layout
LTR- und RTL-Layout im Blocksy-Theme

Was RTL beeinflusst:

RTL-Sprachen erfordern mehr als nur Änderungen der Textrichtung. Dein Theme muss Folgendes verarbeiten:

  • Layout-Richtung: Elemente sollten von rechts nach links fließen
  • Textausrichtung: Text sollte standardmäßig rechtsbündig sein
  • Abstands-Anpassungen: margin-left sollte zu margin-right werden, padding-left sollte zu padding-right werden usw.
  • Navigation: Menüs und Navigation sollten RTL verlaufen
  • Formulare: Eingabefelder und Schaltflächen sollten korrekt ausgerichtet sein
  • Icons und Bilder: Möglicherweise müssen sie gespiegelt oder neu positioniert werden

Was bereits gehandhabt wird:

  • Polylang setzt automatisch die korrekte Sprachrichtung (dir="rtl"-Attribut)
  • Inhaltsübersetzung funktioniert identisch für RTL- und LTR-Sprachen
  • Gato AI Translations übersetzt Inhalte korrekt, unabhängig von der Textrichtung
Polylang-Sprachkonfiguration mit RTL-Sprachen
Polylang erkennt und konfiguriert RTL-Sprachen automatisch

Was du prüfen musst:

  1. RTL-Unterstützung des Themes: Teste dein Theme mit einer RTL-Sprache, um zu sehen, ob es damit korrekt umgeht

    • Viele moderne Themes enthalten RTL-Stylesheets
    • Prüfe die Dokumentation deines Themes auf Informationen zur RTL-Unterstützung
    • Suche in deinem Theme nach rtl.css oder ähnlichen Dateien
  2. Benutzerdefiniertes CSS: Überprüfe jedes benutzerdefinierte CSS, das du hinzugefügt hast

    • Fest codierte Links-/Rechts-Werte müssen möglicherweise angepasst werden
    • Erwäge die Verwendung logischer Eigenschaften (margin-inline-start statt margin-left)
  3. Page-Builder-Kompatibilität: Wenn du Elementor, Bricks oder andere Page Builder verwendest

    • Prüfe, ob sie RTL-Layouts unterstützen
    • Teste Layouts im RTL-Modus vor der Übersetzung

Wenn dein Theme RTL nicht gut unterstützt, musst du möglicherweise zu einem RTL-kompatiblen Theme wechseln, benutzerdefiniertes RTL-CSS hinzufügen oder ein Plugin verwenden, das RTL-Unterstützung hinzufügt.

Inhalte von Drittanbieter-Plugins identifizieren, die übersetzt werden müssen

Viele WordPress-Plugins erstellen ihre eigenen benutzerdefinierten Beitragstypen (CPTs), um Inhalte zu speichern (z. B.: WooCommerce-Produkte, Events-Calendar-Veranstaltungen, LearnDash-Kurse usw.).

Vor der Übersetzung musst du:

  1. Identifizieren, welche CPTs Inhalte enthalten, die übersetzt werden müssen

    • Überprüfe deine aktiven Plugins und deren CPTs
    • Bestimme, welche eine Übersetzung benötigen (nicht alle)
  2. Sicherstellen, dass die relevanten CPTs und Taxonomien übersetzbar sind

    • Gehe zu Languages > Settings > Custom post types and Taxonomies in Polylang
    • Aktiviere die Übersetzung für die relevanten CPTs und Taxonomien
CPTs und Taxonomien für die Übersetzung konfigurieren
CPTs und Taxonomien für die Übersetzung konfigurieren

Übersetzungseinträge für CPTs automatisch erstellen

Wenn ein CPT die Methode wp_insert_post zum Erstellen von Einträgen verwendet, kannst du zur Einstellungsseite unter Plugin Configuration > General Configuration gehen und die Option Automatic creation of translation entries für diesen CPT aktivieren, damit das Plugin die Übersetzungseinträge automatisch erstellt.

Die Option 'Automatic creation of translation entries' einstellen
Die Option 'Automatic creation of translation entries' einstellen

Wenn ein CPT eine andere Methode als wp_insert_post verwendet, musst du Übersetzungseinträge manuell über Polylang's UI erstellen, bevor du sie übersetzen kannst.

Zum Beispiel musst du bei WooCommerce-Produkten zuerst die Übersetzungseinträge erstellen. Sieh dir die Dokumentation zur Übersetzung benutzerdefinierter Beitragstypen von Drittanbietern für ein Demo-Video an.

Sicherstellen, dass dein SEO-Plugin unterstützt wird

SEO-Metadaten (Meta-Titel, Beschreibungen, Open-Graph-Tags usw.) sind entscheidend für mehrsprachige SEO. Gato AI Translations for Polylang bietet integrierte Unterstützung für die beliebtesten SEO-Plugins und übersetzt automatisch alle SEO-bezogenen Metadaten.

Das Plugin unterstützt 8 wichtige SEO-Plugins:

  1. All in One SEO
  2. Rank Math
  3. SEO Simple Pack
  4. SEOPress
  5. Slim SEO
  6. The SEO Framework
  7. WP Meta SEO
  8. Yoast SEO

Wenn du ein SEO-Plugin verwendest, das nicht in der obigen Liste aufgeführt ist, musst du angeben, welche Meta-Keys synchronisiert und übersetzt werden sollen, entsprechend dem SEO-Plugin, das du verwendest. Jedes Plugin, das seine Metadaten in der wp_postmeta-Tabelle speichert, wird unterstützt.

KI-Anbieter und Modell wählen

Die Qualität deiner Übersetzungen hängt vom gewählten KI-Dienst und Modell ab.

Moderne KI-Dienste (wie ChatGPT, Claude und Gemini) produzieren deutlich bessere Übersetzungen als ältere Dienste (Google Translate oder DeepL), weil sie Kontext, Ton und Nuancen besser verstehen; HTML-Struktur und Formatierung korrekt beibehalten; URLs oder relative Links nicht falsch übersetzen; Schreibstil und Sprache konsistent über alle Übersetzungen hinweg beibehalten; und mit Fachbegriffen und fachspezifischer Sprache besser umgehen.

Du kannst aus folgenden KI-Diensten wählen:

  • ChatGPT (OpenAI)
  • Claude (Anthropic)
  • DeepSeek
  • Gemini (Google)
  • Mistral AI
  • OpenRouter (LLM-Aggregator, der Zugang zu allen wichtigen Modellen bietet, einschließlich Grok und Llama)
  • Self-hosted LLM (auf deinem eigenen Server gehostet, z. B. über Ollama)

Wir empfehlen, die neuesten verfügbaren Modellversionen zu verwenden (z. B.: ChatGPT 5.2 statt 5.0), da neuere Modelle konstant bessere Übersetzungsqualität liefern.

Profi-Tipp: Du kannst verschiedene KI-Dienste für verschiedene Sprachen konfigurieren. Verwende zum Beispiel DeepSeek für Chinesisch (ausgezeichnete Qualität und sehr erschwinglich), ChatGPT für europäische Sprachen und Claude für komplexe technische Inhalte. So kannst du sowohl Qualität als auch Kosten optimieren.

Du kannst OpenRouter verwenden, um auf die neuesten KI-Modelle zuzugreifen, sobald sie veröffentlicht werden.

Den KI-Übersetzungs-Prompt anpassen

Der Standard-Übersetzungs-Prompt funktioniert gut für die meisten Inhalte, aber eine Anpassung kann die Übersetzungsqualität für deinen spezifischen Anwendungsfall verbessern.

Beispiel:

Ein Reiseblog könnte seinen Prompt anpassen, indem er Folgendes hinzufügt:

Translate to a natural, flowing, easy-to-read, casual blog-style language. Keep original content structure, meaning, and styling (but do adjust sentence structure and style to be relevant to the target language).
 
Lightly improve boring parts - Add curiosity triggers, light humor, and light slang (as fits the target language), like a human travel blogger would write.

Du kannst den Standard-Prompt ändern oder mehrere benutzerdefinierte KI-Prompts erstellen und auswählen, welchen du in den Einstellungen verwenden möchtest:

Bearbeiten eines KI-Prompts
Systemnachricht und Prompt-Vorlage für benutzerdefinierte Prompts bearbeiten

Gutenberg-Blöcke prüfen

Bevor du übersetzt, musst du identifizieren, welche Blöcke du verwendest, und sicherstellen, dass sie für die Übersetzung unterstützt werden.

Gutenberg-Blöcke out of the box unterstützt:

  • Alle WordPress-Core-Blöcke: Paragraph, Heading, List, Quote, Image, Gallery usw.
  • Blöcke von Drittanbietern: Blöcke von Plugins Yoast SEO, GenerateBlocks, Kadence, Greenshift usw.

Wenn du einen nicht unterstützten Block verwendest, der zu übersetzende Zeichenketten enthält, kannst du entweder:

Brauchst du Hilfe? Wir können benutzerdefinierte Blöcke für dich integrieren. Schau dir unsere individuellen Dienstleistungen an, wenn du möchtest, dass Experten die Integration übernehmen.

Hinweis: Es gibt Blöcke, die nicht übersetzt werden können.

Wenn du einen nicht unterstützten Block ersetzen musst, möchtest du alle Beiträge finden, die ihn verwenden. Schau dir das Tutorial zum Finden von Beiträgen, die einen bestimmten Block enthalten an, um Methoden zur Identifizierung der Verwendung bestimmter Blöcke zu erhalten.

Elementor-Widgets prüfen

Wenn du den Elementor Page Builder verwendest, musst du prüfen, welche Widgets du verwendest, und sicherstellen, dass sie für die Übersetzung unterstützt werden. Der Prozess ähnelt dem Prüfen von Gutenberg-Blöcken, ist aber spezifisch für Elementor-Widgets.

Alle Elementor-Core-Widgets werden out of the box unterstützt.

Wenn du nicht unterstützte Widgets hast:

Bricks-Elemente prüfen

Wenn du den Bricks Page Builder verwendest, musst du prüfen, welche Elemente du verwendest, und sicherstellen, dass sie für die Übersetzung unterstützt werden. Der Prozess ähnelt dem Prüfen von Gutenberg-Blöcken, ist aber spezifisch für Bricks-Elemente.

Alle Bricks-Core-Elemente werden out of the box unterstützt.

Wenn du nicht unterstützte Elemente hast:

Mit Text versehene Bilder behandeln

Ein häufiger Fehler bei der Übersetzung von Websites ist, zu vergessen, dass Bilder Text enthalten können, der möglicherweise übersetzt werden muss.

Wenn du einen Beitrag übersetzt, werden die Bilder in die übersetzte Version kopiert, und Bild-Metadaten (Titel, Alt-Text, Bildunterschrift) werden übersetzt, aber jeder Text innerhalb dieser Bilder bleibt in der Originalsprache.

Um deine Bilder zu prüfen, ist der einfachste Weg, die WordPress-Mediathek auf das Raster-Layout umzustellen — so kannst du alle deine Bilder auf einen Blick visuell durchsehen und schnell solche erkennen, die eingebetteten Text in der falschen Sprache enthalten.

WordPress-Mediathek im Raster-Layout
Verwende das Raster-Layout in der Mediathek, um alle Bilder visuell auf eingebetteten Text zu prüfen

Dieses Bild enthält zum Beispiel hebräischen Text und ist daher für andere Sprachen ungeeignet.

Karte von Thailand mit hebräischem Text
Bilder können Text enthalten, der bei der Übersetzung berücksichtigt werden muss

Deine Optionen:

  1. Eingebetteten Text beibehalten (wenn die Sprache allgemein noch verstanden werden kann)

    • Geeignet, wenn der Text in einer weitverständlichen Sprache verfasst ist oder universelle Symbole/Zahlen verwendet
    • Kein zusätzlicher Aufwand erforderlich
  2. Text aus Bildern entfernen

    • Verwende Bilder ohne eingebetteten Text
  3. Text-Overlays statt eingebettetem Text verwenden

    • Verwende Bilder ohne eingebetteten Text
    • Überlagere Text (mit Gutenberg-Blöcken, Elementor-Widgets, Bricks-Elementen oder CSS), der automatisch übersetzt wird
  4. Übersetzte Versionen der Bilder erstellen

    • Erstelle separate Bilddateien für jede Sprache
    • Ersetze Bilder in übersetzten Beiträgen manuell

Übersetzung zusätzlicher Benutzerdaten behandeln

Polylang kann das Biografiefeld für WordPress-Benutzerprofile verwalten, aber wenn du zusätzliche Benutzerdaten in benutzerdefinierten Feldern (über ACF, Meta Box oder andere Mittel) gespeichert hast, benötigst du einen speziellen Ansatz.

Wenn du Benutzerdaten hast, die übersetzt werden müssen (z. B. Berufsbezeichnungen, Qualifikationen, Beschreibungen usw.), musst du separate Felder für jede Sprache erstellen.

  1. Separate Felder für jede Sprache erstellen

    • Erstelle mit ACF oder Meta Box Felder wie:
      • Qualification EN
      • Qualification FR
      • Qualification DE
      • usw.
  2. Dein Theme aktualisieren, um das korrekte Feld anzuzeigen

    • Ändere deine Theme-Templates, um die aktuelle Sprache zu prüfen
    • Zeige das entsprechende Feld basierend auf der aktiven Sprache an
    • PHP-Code-Beispiel:
      $current_lang = pll_current_language();
      $qualification = get_field("qualification_{$current_lang}", 'user_' . $user_id);
      echo $qualification;
  3. Felder manuell befüllen

    • Nach der Übersetzung der Inhalte Benutzerprofilfelder manuell aktualisieren

Übersetzung von Begriffen überspringen, die nicht übersetzt werden sollen

Einige Begriffe sollten niemals übersetzt werden — Markennamen, Eigennamen, Fachbegriffe oder fachspezifische Terminologie.

Du kannst die Übersetzung dieser Begriffe überspringen, indem du deinem benutzerdefinierten Prompt Anweisungen hinzufügst, zum Beispiel:

Do not translate the following types of terms:
- Hotel names (e.g., "Grand Hotel", "Beach Resort")
- Restaurant names
- Brand names
- Technical acronyms (API, SEO, CMS, etc.)
 
Keep these terms exactly as they appear in the original text.

Doppelte Tags über Sprachen hinweg vermeiden

Unser Inhalt kann Tags enthalten, die dasselbe Konzept in zwei verschiedenen Sprachen darstellen. Wenn diese Tags übersetzt werden, können sie Duplikate oder Konflikte erzeugen.

Wenn du zum Beispiel eine chinesische Website ins Englische übersetzt und du sowohl einen Tag 布宜诺斯艾利斯 (Buenos Aires auf Chinesisch) als auch einen Tag Buenos Aires auf Englisch hast, werden bei der Übersetzung ins Englische beide Tags zu buenos-aires. Das erzeugt eine Situation mit doppeltem Tag.

Doppelter Tag über 2 Sprachen hinweg
Doppelter Tag über 2 Sprachen hinweg

Wie du das vor der Übersetzung behebst:

  1. Deine Tags prüfen

    • Überprüfe alle Tags in deiner Ursprungssprache
    • Identifiziere Tags, die Duplikate von Tags in anderen Sprachen sein könnten
    • Suche nach Tags, die dasselbe Konzept, aber in verschiedenen Sprachen darstellen
  2. Tags konsolidieren

    • Wähle eine Sprachversion aus, die du behalten möchtest (typischerweise deine Ursprungssprache)
    • Zusammenführen oder Entfernen doppelter Tags
    • Aktualisiere Beiträge, um den konsolidierten Tag zu verwenden
  3. Vor der Übersetzung aufräumen

    • Stelle sicher, dass dein Ursprungsinhalt nur Tags in der Ursprungssprache hat
    • Entferne alle Tags in Zielsprachen aus dem Ursprungsinhalt
    • Das verhindert Konflikte während der Übersetzung

Doppelte Ortsnamen über Sprachen hinweg vermeiden

Wenn dein Inhalt Überschriften verwendet, die verschiedene Schriften mischen, siehst du möglicherweise dieses Muster: Der Titel beginnt mit einem lokalen Ortsnamen, dann folgt derselbe Name in lateinischen Buchstaben in Klammern, dann der Rest der Zeile.

Typisches Ursprungsmuster (Beispiel):

  • Ursprung (z. B. auf Hebräisch): פוקט (Pouket) - מדריך לאי היפה — lokaler Name, dann eine englische oder internationale Schreibweise in Klammern, dann der Untertitel.
  • Übersetzt (z. B. ins Englische): Pouket (Pouket) - beautiful island guide.

Nach der Übersetzung ist die Überschrift bereits in einer Sprache und Schrift, sodass die wörtliche Wiedergabe des Modells denselben Ortsnamen zweimal wiederholt (z. B. Pouket (Pouket)).

Lösung: Den Übersetzungs-Prompt präzisieren

Passe deinen Prompt an, damit das Modell redundante "Name (GleicherName)"-Anfänge normalisiert, wenn die Klammer keine neuen Informationen hinzufügt. Füge zum Beispiel Anweisungen wie diese hinzu:

If a heading begins with a place name followed by the same translated name in parentheses, remove the duplicate and keep one natural version. Do not remove the parenthesis if the text inside uses a different script, a different spelling, or includes additional descriptive information.

Auf deine Tag-/Kategorie-Slugs achten

Wenn deine Tag- oder Kategorie-Slugs bereits in der Zielsprache vorliegen, könntest du annehmen, dass es nichts zu übersetzen gibt.

Kategorien auf Hebräisch haben ihren Slug auf Englisch
Kategorien auf Hebräisch haben ihren Slug auf Englisch

Das ist oft in Ordnung — aber es gibt einen Haken mit Polylang free (nicht Pro).

Mit Polylang Pro können übersetzte Begriffe denselben Slug über Sprachen hinweg wiederverwenden. Mit der kostenlosen Version erzwingt WordPress einzigartige Slugs generell, sodass der übersetzte Begriff-Slug automatisch ein -2-Suffix erhält.

Zum Beispiel: Eine Kategorie mit dem Slug travels_and_attractions auf Hebräisch wird bei der Übersetzung ins Englische zu travels_and_attractions-2, anstatt denselben Slug beizubehalten.

Wenn das deine URLs oder SEO beeinflusst, musst du die Slugs nach der Übersetzung manuell korrigieren oder auf Polylang Pro upgraden, um die Wiederverwendung von Slugs über Sprachen hinweg zu ermöglichen.

Sicherstellen, dass deine Einbettungen in einer akzeptablen Sprache sind

Wenn du Inhalte von Drittanbietern einbettest — wie Google Maps, Social-Media-Widgets oder andere Plattform-iFrames — prüfe, ob die Einbettung in der Zielsprache angezeigt wird.

Ein Google-Maps-Einbettung, die für Hebräisch konfiguriert ist, zeigt zum Beispiel weiterhin hebräische Beschriftungen, Straßennamen und Benutzeroberfläche an, auch nachdem du den Rest der Seite ins Englische übersetzt hast. In diesem Fall möchtest du möglicherweise eine sprachneutrale Einbettung verwenden.

Google-Maps-Einbettung mit hebräischen Informationen auf einer englischen Seite
Diese Google-Maps-Einbettung zeigt weiterhin hebräische Informationen — nach der Übersetzung der Website ins Englische nicht geeignet

Dasselbe gilt für jede Plattform oder jeden Dienst, der sprachspezifische Einbettungen generiert (z. B. YouTube-Kapitel, Bewertungs-Widgets, Buchungsformulare). Überprüfe nach der Übersetzung immer jede Einbettung.

Sicherstellen, dass kein sprachspezifisches Styling im Ursprungsinhalt vorhanden ist

Beitragsinhalt, der für eine bestimmte Sprache geschrieben wurde — insbesondere RTL-Sprachen wie Hebräisch oder Arabisch — kann Inline-Richtungs- und Sprachattribute enthalten, die direkt auf HTML-Elemente angewendet werden. Wenn dieser Inhalt in eine andere Sprache übersetzt wird, übertragen sich diese fest codierten Stile und brechen das Layout.

Häufige Probleme in RTL-Ursprungsinhalt:

  • <div dir="rtl" lang="he"> — erzwingt RTL-Richtung und markiert die Sprache als Hebräisch für einen gesamten Abschnitt
  • <p dir="rtl"> — erzwingt RTL-Ausrichtung für einzelne Absätze
  • <h2 style="text-align: right;"> — fest codierte Rechtsausrichtung für Überschriften

Wenn dieser Inhalt ins Englische (oder eine andere LTR-Sprache) übersetzt wird, wird der Text englisch, aber das Layout wird weiterhin von rechts nach links dargestellt — was zu falsch ausgerichteten Überschriften, umgekehrtem Textfluss und defekter Formatierung führt.

Bevor du übersetzt, prüfe deinen Ursprungsinhalt auf diese Attribute und entferne sie. Lass das Theme und die Sprach-/Locale-Einstellungen von WordPress die Richtung und Ausrichtung global steuern, anstatt sie in einzelne Inhaltsblöcke einzubetten.

Elementor-Theme-Builder-Templates behandeln

Wenn du den Theme Builder von Elementor verwendest, um globale Templates zu erstellen (Header, Footer, Einzelbeitrags-Templates, Archiv-Templates usw.), ist es wichtig zu verstehen, wie diese Templates während der Übersetzung gehandhabt werden.

Was übersetzt wird:

  • Menüs: Menüelemente werden durch übersetzte Menüversionen ersetzt
  • Dynamischer Inhalt: Aus Beiträgen/Seiten abgerufener Inhalt wird übersetzt (da der Quellinhalt übersetzt ist)

Was nicht übersetzt wird:

  • Fest codierter Text: Jeder Text, der direkt zum Template hinzugefügt wurde (nicht aus dynamischen Inhalten), wird NICHT übersetzt
  • Widget-Text: Text in Widgets wie Überschriften, Absätzen, Schaltflächen usw. bleibt in der Ursprungssprache
  • Benutzerdefiniertes HTML: Alle benutzerdefinierten HTML- oder Code-Blöcke bleiben unübersetzt

Beispiel:

Dieses Elementor-Header-Template enthält fest codierten Text ("Our Phone Number:"):

Elementor-Header-Template
Elementor-Header-Template

Lösung:

Gestalte Templates so, dass sie nur Folgendes verwenden:

  • Menüs (die automatisch ersetzt werden)
  • Bilder (die sprachneutral sind)
  • Dynamischer Inhalt (der aus übersetzten Beiträgen stammt)
  • Vermeide das direkte Hinzufügen von fest codiertem Text, Überschriften oder Beschreibungen in Templates

Das stellt sicher, dass die globalen Elemente deiner Website (Header, Footer usw.) in allen Sprachen korrekt funktionieren.

Advanced Custom Fields (ACF) konfigurieren

Wenn du Advanced Custom Fields (ACF) verwendest, musst du konfigurieren, wie jedes Feld während der Übersetzung gehandhabt werden soll. ACF-Felder können verschiedene Inhaltstypen enthalten, und jeder Typ benötigt möglicherweise eine unterschiedliche Behandlung.

Im Gato Translate-Abschnitt können ACF-Felder auf eine dieser Optionen gesetzt werden:

  1. (Do nothing): Das Feld wird bei der Übersetzung oder Synchronisierung übersprungen

  2. Translate: Der Feldinhalt wird in die Zielsprache übersetzt

    • Verwenden für: Textfelder, Textarea-Felder, WYSIWYG-Felder und alle Felder mit übersetzbarem Text
  3. Copy: Der Feldwert wird unverändert in die Übersetzung kopiert (nicht übersetzt)

    • Verwenden für: Zahlen, Datumsangaben, Checkboxes, Wahr/Falsch-Felder und alle Felder, die nicht übersetzt werden sollen
  4. Translate Reference: Das Feld referenziert eine andere Entität (Beitrag, Seite, Benutzer usw.), und die Referenz wird aktualisiert, um auf die übersetzte Version zu zeigen

    • Verwenden für: Post-Object-, Page-Link-, Relationship-, User- und Taxonomy-Felder
Konfiguration der Übersetzungsoption für ein ACF-Feld
Übersetzungsoptionen für jedes ACF-Feld konfigurieren (Translate, Copy oder Translate Reference)

Field Groups können auf mehr als nur Beiträge und Seiten angewendet werden. Sie können auch auf Folgendes angewendet werden:

  • Kategorien
  • Tags
  • Medienelemente
  • Benutzer
  • Benutzerdefinierte Taxonomien
  • Benutzerdefinierte Beitragstypen

Stelle sicher, dass du auch Übersetzungseinstellungen für Field Groups konfigurierst, die für diese Entitäten gelten!

Wenn du Polylang Pro verwendest, musst du auch dessen ACF-Übersetzungsfunktionen deaktivieren, damit Gato AI Translations die Übersetzung stattdessen übernehmen kann.

Meta Box konfigurieren

Wenn du Meta Box verwendest (ein weiteres beliebtes Plugin für benutzerdefinierte Felder), ist der Konfigurationsprozess ähnlich wie bei ACF. Meta-Box-Felder müssen ebenfalls für Übersetzung, Kopieren oder Referenzübersetzung konfiguriert werden.

Im Gato Translate-Abschnitt können Meta-Box-Felder auf eine dieser Optionen gesetzt werden:

  1. (Do nothing): Das Feld wird bei der Übersetzung oder Synchronisierung übersprungen
  2. Translate: Feldinhalt wird übersetzt
  3. Copy: Feldwert wird unverändert kopiert
  4. Translate Reference: Feldreferenz wird aktualisiert, um auf die übersetzte Entität zu zeigen
Konfiguration der Synchronisierung/Übersetzung für eine Meta-Box-Feldgruppe
Konfiguration der Synchronisierung/Übersetzung für eine Meta-Box-Feldgruppe

Du musst auch Polylang's Meta-Box-Übersetzungsfunktionen deaktivieren, damit Gato AI Translations die Übersetzung stattdessen übernehmen kann.

Benutzerdefinierte Meta-Felder konfigurieren

Neben ACF, Meta Box und SEO-Plugins kann deine Website weitere benutzerdefinierte Meta-Felder haben von:

  • Benutzerdefiniertem Code
  • Anderen Plugins
  • WordPress-benutzerdefinierten Feldern (das grundlegende Custom-Fields-Metabox)

Diese Meta-Felder müssen manuell in den Plugin-Einstellungen konfiguriert werden.

Benutzerdefinierte Meta-Keys identifizieren:

  1. Deinen Inhalt exportieren

    • Gehe zu Tools > Export in WordPress
    • Exportiere alle Inhaltstypen, die du übersetzen möchtest
    • Das erstellt eine XML-Datei mit allen deinen Inhalten und Metadaten
  2. Die Exportdatei analysieren

    • Öffne die XML-Datei in einem Texteditor
    • Suche nach <wp:postmeta>-Tags
    • Liste alle einzigartigen Meta-Keys auf
  3. Bekannte Felder herausfiltern

    • Entferne ACF-Felder (typischerweise mit deinem Feldgruppen-Namen als Präfix)
    • Entferne Meta-Box-Felder
    • Entferne WordPress-Core-Felder (z. B. _edit_last, _wp_old_slug, _thumbnail_id)
    • Entferne SEO-Plugin-Felder (wenn du ein unterstütztes SEO-Plugin verwendest)
  4. Identifiziere, was übrig bleibt

    • Das sind deine benutzerdefinierten Meta-Felder
    • Bestimme, was jedes Feld enthält und wie es behandelt werden soll

Übersetzungsbedarf bestimmen:

Bestimme für jedes benutzerdefinierte Meta-Feld:

  • Translate: Enthält übersetzbaren Text (Titel, Beschreibungen, Inhalt)
  • Copy: Enthält Daten, die nicht übersetzt werden sollen (IDs, Zahlen, Einstellungen)
  • Translate Reference: Enthält Entitäts-IDs, die auf übersetzte Versionen zeigen sollen

Im Plugin konfigurieren:

  1. Gehe zu den Einstellungen unter dem Tab Meta Configuration
  2. Wähle die Übersetzungsoption (Translate/Copy/Translate Reference)
  3. Füge die benutzerdefinierten Meta-Key-Namen hinzu, mit einer genauen Übereinstimmung oder einem Regex-Muster
Konfiguration der Meta-Keys für die Übersetzung
Benutzerdefinierte Meta-Keys für die Übersetzung in den Plugin-Einstellungen konfigurieren

Den Übersetzungsprozess durchführen

Jetzt, wo alle Vorbereitungen abgeschlossen sind, ist es Zeit, die Übersetzungen durchzuführen.

Den Prozess zuerst testen

Bevor du dich in die Übersetzung deiner gesamten Website stürzt, ist es wichtig, den Prozess zunächst in kleinem Maßstab zu testen. Dieser Ansatz spart dir Zeit und verhindert, dass Probleme in alle deine Inhalte repliziert werden.

Hier ist der empfohlene Test-Workflow:

  1. Mit einem einzelnen Beitrag und einer Sprache beginnen

    • Wähle einen repräsentativen Beitrag, der verschiedene Inhaltstypen enthält (Text, Bilder, Links usw.)
    • Übersetze ihn in nur eine Zielsprache, die du gut verstehst
    • Validiere die Übersetzung im Detail: überprüfe jeden Block, jeden Link, jedes Bild und jedes Metadatenelement
    • Wenn du ein Problem entdeckst (z. B. ein Block wurde nicht übersetzt, ein Link wurde nicht ersetzt, die Formatierung wurde unterbrochen), behebe es vor dem Fortfahren. Dasselbe Problem wird für alle Sprachen repliziert, wenn du es jetzt nicht behebst.
  2. Auf weitere Beiträge ausweiten

    • Sobald die erste Übersetzung perfekt ist, übersetze 3-5 weitere Beiträge in dieselbe Sprache
    • Validiere jeden sorgfältig
    • Das hilft dir, Muster oder wiederkehrende Probleme zu identifizieren
  3. Mit weiteren Sprachen testen

    • Wenn du in mehrere Sprachen übersetzt, teste mit einer weiteren Sprache, um sicherzustellen, dass alles über verschiedene Sprachpaare hinweg funktioniert
  4. Erst dann mit der Massenübersetzung fortfahren

    • Sobald du sicher bist, dass alles korrekt funktioniert, kannst du mit der Übersetzung des restlichen Teils deiner Website fortfahren

Dieser inkrementelle Ansatz stellt sicher, dass Konfigurationsprobleme oder Inhaltsprobleme frühzeitig erkannt werden, wenn sie leicht zu beheben sind.

Übersetzungsreihenfolge

Die Reihenfolge, in der du verschiedene Inhaltstypen übersetzt, ist wichtig, insbesondere wenn Inhalte andere Inhalte referenzieren.

Übersetze Inhalte in dieser spezifischen Reihenfolge, um Referenzprobleme zu vermeiden:

  1. Users

    • Benutzerbeschreibungen können in Blöcken enthalten sein
  2. Taxonomies (Tags/Categories)

    • Tags und Kategorien (und benutzerdefinierte Taxonomien) werden oft von Beiträgen referenziert und müssen daher vorhanden sein, bevor Beiträge übersetzt werden
  3. Media

    • Medienelemente (Bilder, Videos, Dokumente) werden von Beiträgen als Beitragsbilder oder Galeriebilder referenziert, also übersetze sie vor den Beiträgen
  4. Custom Post Types

    • Übersetze Beiträge, Seiten und andere CPTs
    • Wichtig: Wenn ein CPT einen anderen referenziert, übersetze in umgekehrter Abhängigkeitsreihenfolge
    • Zum Beispiel: Wenn Beiträge wiederverwendbare Blöcke verwenden, übersetze zuerst wiederverwendbare Blöcke, dann Beiträge
  5. Menus

    • Übersetze Menüs zuletzt, da sie Beiträge, Seiten und Kategorien referenzieren

Entscheiden, ob Slugs übersetzt werden sollen oder nicht

Das Übersetzen von Beitrags- und Taxonomie-Slugs in die Zielsprache ist oft wünschenswert für Sprachen mit lateinischer Schrift (z. B. Französisch, Deutsch, Spanisch): Der Pfad bleibt lesbar und du kannst lokalisierte Schlüsselwörter in der URL widerspiegeln.

Für nicht-lateinische Schriften — Hebräisch, Japanisch, Chinesisch und ähnliche — werden lokalisierte Slugs oft zu einem Durcheinander: ungeschickte Transliterationen, sehr lange Segmente, Prozent-Kodierung oder URLs, die schwer zu teilen und zu vergleichen sind. Viele Teams behalten lateinische (oder ursprachige) Slugs für diese Sprachen und verlassen sich auf den übersetzten Titel für den sichtbaren, lokalisierten Namen.

Behandle die Slug-Übersetzung als Richtlinie pro Zielsprache, nicht als einfachen Ein/Aus-Schalter für die gesamte Website:

  1. Sprachen in Gruppen aufteilen — z. B. "Slugs übersetzen" für lateinische Zielsprachen vs. "Slugs nicht übersetzen" für Chinesisch, Japanisch, Hebräisch usw.
  2. Separate Übersetzungs-Batches ausführen — übersetze in großen Mengen in eine Gruppe mit aktivierter Slug-Übersetzung, dann führe einen weiteren Batch in die andere Gruppe mit deaktivierter Slug-Übersetzung aus.
  3. Jeden Batch konfigurieren über Gato Translate (Custom) (behandelt unter Wie man Übersetzungen ausführt unten): Deaktiviere Optionen wie Translate custom post slugs? und Translate tag and category slugs? für Batches, bei denen du Slugs unverändert lassen möchtest. Strebe nach einer Richtlinie pro Ausführung (z. B. eine Sprache oder eine Gruppe von Sprachen, die dieselbe Regel teilen), damit die Einstellungen dem erwarteten Ergebnis entsprechen.

Für geskriptete oder wiederholbare Workflows unterstützt WP-CLI --translate-slugs=true oder --translate-slugs=false pro Aufruf.

Zweistufige Übersetzung

Wenn du die Ersetzung interner Links oder die Übersetzung von Entitätsreferenzen aktiviert hast, musst du möglicherweise in zwei Durchgängen übersetzen:

Durchgang 1: Nur Eigenschaften übersetzen

  1. Konfiguriere die Übersetzung so, dass Inhalt und Meta ausgeschlossen werden, d. h. übersetze nur Eigenschaften (Titel/Name und Slug)
  2. Übersetzung durchführen
Nur Beitragseigenschaften (Titel, Slug) für die Übersetzung auswählen
Erster Durchgang: Nur Eigenschaften (Titel, Slug) übersetzen, um übersetzte Einträge zu erstellen

Nach dem ersten Durchgang werden die übersetzten Beiträge mit ihren übersetzten URLs und IDs erstellt, sodass interne Link-URLs und Entitätsreferenz-IDs in die Zielsprache aufgelöst werden können.

Durchgang 2: Nur Inhalt und Meta übersetzen

  1. Konfiguriere die Übersetzung so, dass nur Inhalt und Meta übersetzt werden (d. h. Eigenschaften ausschließen)
  2. Übersetzung erneut durchführen
Nur Beitragsinhalt und Meta für die Übersetzung auswählen
Zweiter Durchgang: Nur Inhalt und Meta übersetzen, um interne Links und Entitätsreferenzen zu ersetzen

Nach dem zweiten Durchgang werden die verbleibenden Inhalte und Meta übersetzt, und interne Link-URLs sowie Entitätsreferenz-IDs werden durch die übersetzten Versionen ersetzt.

Wie man Übersetzungen ausführt

Option 1: WordPress-Administration (Bulk Actions)

  1. Gehe zur Inhaltsliste (Beiträge, Seiten, Medien usw.)
  2. Wähle die Elemente aus, die du übersetzen möchtest
  3. Wähle Gato Translate aus dem Bulk-Actions-Dropdown
  4. Klicke auf Anwenden
Die Gato-Translate-Aktion ausführen
Bulk Actions verwenden, um mehrere Elemente gleichzeitig zu übersetzen

Menüs werden anders übersetzt: Sie werden automatisch übersetzt, wenn du sie im Menü-Editor speicherst.

Alternative: Gato Translate (Custom)

Für mehr Kontrolle verwende Gato Translate (Custom), mit dem du Einstellungen für diese spezifische Übersetzungsausführung überschreiben kannst:

Die Bulk Action Gato Translate (Custom) ausführen
Gato Translate (Custom) für benutzerdefinierte Einstellungen pro Übersetzung verwenden

Das öffnet eine benutzerdefinierte Einstellungsseite, auf der du spezifische Optionen für diese Übersetzungsausführung angeben kannst:

Anpassen der Ausführung der Aktion 'Gato Translate'
Übersetzungseinstellungen für diese spezifische Ausführung anpassen

Option 2: WP-CLI (für große Batches)

Für große Websites mit Hunderten oder Tausenden von Elementen ist WP-CLI eine praktische Alternative.

Du kannst Übersetzungen als Batch über die Befehlszeile ausführen und die Übersetzungen im Hintergrund ausführen lassen, während du an etwas anderem arbeitest.

Das Skript 'gatotranslate.sh' ausführen
Das Skript 'gatotranslate.sh' ausführen

Übersetzungsprotokolle überprüfen

Wenn eine Übersetzung fehlschlägt (wegen API-Ausfall, erschöpften API-Credits usw.) oder Warnungen erzeugt, wird im Plugin-Menü ein Benachrichtigungs-Badge angezeigt:

Die Übersetzung des Beitrags 'Hello World' ins Spanische ist fehlgeschlagen, und ein Benachrichtigungs-Badge wird angezeigt
Ein Benachrichtigungs-Badge erscheint, wenn Übersetzungen fehlschlagen

Überprüfe die Übersetzungsprotokolle, um zu verstehen, was passiert ist:

  1. Gehe zum Menüelement Logs im Plugin-Menü
  2. Überprüfe alle Fehler oder Warnungen
  3. Behebe alle Probleme, bevor du fortfährst
Protokolle durchsuchen
Übersetzungsprotokolle durchsuchen, um Probleme zu identifizieren
Einzelnes Protokoll anzeigen
Detaillierten Protokolleintrag anzeigen, um den Fehler zu verstehen

Fehlgeschlagene Übersetzungen erneut ausführen

Wenn eine Übersetzung fehlschlägt, kannst du die Übersetzung nur dieses Eintrags und dieser Sprache erneut auslösen und vermeidest, API-Credits für erfolgreiche Übersetzungen auszugeben.

Fehlgeschlagene Übersetzungen werden mit einem gelben Hintergrund auf dem Polylang-Bearbeitungssymbol hervorgehoben:

Gelber Hintergrund auf dem Polylang-Bearbeitungssymbol für fehlgeschlagene Übersetzungen
Fehlgeschlagene Übersetzungen werden mit einem gelben Hintergrund hervorgehoben

Du kannst filtern, um nur Einträge mit fehlgeschlagenen Übersetzungen anzuzeigen:

Filtern, um nur Einträge mit fehlgeschlagenen Übersetzungen anzuzeigen
Filtern, um nur fehlgeschlagene Übersetzungen anzuzeigen

Um nur die fehlgeschlagenen Einträge erneut zu übersetzen, verwende die Bulk Action Gato Translate (Custom) mit der Option Process failed translations only:

Filtern, um nur Einträge mit fehlgeschlagenen Übersetzungen anzuzeigen
Liste der Einträge mit fehlgeschlagenen Übersetzungen
Die Option 'Process failed translations only' auf der Einstellungsseite von 'Gato Translate (Custom)' auswählen
Übersetzungen nur für fehlgeschlagene Einträge erneut ausführen

Übersetzungsqualität und -vollständigkeit validieren

Nach der Übersetzung von Inhalten ist es wichtig zu validieren, dass die Übersetzungen erfolgreich und von guter Qualität sind. Nehme nicht an, dass alles perfekt funktioniert hat — nimm dir Zeit zum Überprüfen.

Validierung im Editor:

Öffne übersetzte Beiträge im WordPress-Editor und prüfe:

  1. Inhaltsübersetzung

    • Ist der gesamte Text übersetzt? (nicht nur der Titel)
    • Sind alle Blöcke/Widgets/Elemente übersetzt?
    • Gutenberg-Blöcke, Elementor-Widgets oder Bricks-Elemente prüfen
    • Überprüfen, ob die Formatierung erhalten geblieben ist
  2. Benutzerdefinierte Felder

    • Sind ACF-Felder korrekt übersetzt/kopiert/referenziert?
    • Werden Meta-Box-Felder korrekt behandelt?
    • Sind benutzerdefinierte Meta-Felder korrekt konfiguriert?
  3. SEO-Metadaten

    • Prüfen, ob Meta-Titel übersetzt sind
    • Sicherstellen, dass Meta-Beschreibungen übersetzt sind
    • Bestätigen, dass Open-Graph-Tags übersetzt sind
    • Alle weiteren Felder des SEO-Plugins überprüfen
  4. Medien

    • Sind Beitragsbilder korrekt gesetzt?
    • Zeigen Bilder im Inhalt auf übersetzte Versionen (falls zutreffend)?
    • Sind Bild-Alt-Texte übersetzt?
  5. Links

    • Zeigen interne Links auf übersetzte Versionen?
    • Sind externe Links korrekt erhalten?
    • Funktionieren Kategorie-/Tag-Links?

Frontend-Validierung:

Zeige übersetzte Beiträge im Browser an und überprüfe:

  1. Visuelles Erscheinungsbild

    • Sieht die Seite korrekt aus?
    • Ist das Layout erhalten?
    • Werden Bilder korrekt angezeigt?
    • Ist das Styling korrekt?
  2. Template-Anwendung

    • Wird das korrekte Template verwendet?
    • Werden Header/Footer korrekt angezeigt?
    • Werden Seitenleisten/Widgets angezeigt?
    • Zeigt das Menü die übersetzte Version?
  3. Funktionalität

    • Funktionieren alle Links?
    • Funktionieren Formulare?
    • Funktionieren interaktive Elemente?
    • Ist die Navigation korrekt?
  4. Sprachspezifische Elemente

    • Ist das Layout für RTL-Sprachen korrekt?
    • Werden Schriften korrekt gerendert?
    • Ist die Textrichtung korrekt?

Übersetzungsqualität:

Moderne KI-Übersetzung ist im Allgemeinen sehr gut, aber du solltest trotzdem überprüfen:

  1. Sprachen, die du verstehst

    • Übersetzungen in Sprachen lesen, die du kennst
    • Auf Genauigkeit, Ton und Stil prüfen
    • Überprüfen, ob Fachbegriffe korrekt sind
    • Sicherstellen, dass die Markenstimme beibehalten wird
  2. Sprachen, die du nicht verstehst

    • Für Sprachen, die du nicht sprichst, erwäge, einen Muttersprachler zur Überprüfung hinzuzuziehen
    • Das ist besonders wichtig für Sprachen, die sehr verschieden von deiner eigenen sind (z. B. Englisch zu Koreanisch, Chinesisch, Arabisch)
    • Selbst eine kurze Überprüfung kann größere Probleme erkennen
    • Professionelles Korrekturlesen wird für wichtige Inhalte empfohlen
  3. Fachspezifische Inhalte

    • Technische Inhalte benötigen möglicherweise eine Fachprüfung
    • Rechtliche/medizinische Inhalte sollten von Fachleuten überprüft werden
    • Marketinginhalte benötigen möglicherweise Anpassungen der Markenstimme

"Ungültige Inhalte"-Blöcke reparieren

Beim Übersetzen großer HTML-Blobs, die viele Tags und Attribute enthalten, können KI-Dienste manchmal eine Antwort zurückgeben, die die Ausgabe des Blocks beschädigt.

Zum Beispiel beim Übersetzen eines core/paragraph-Blocks, der einen sehr großen HTML-Blob mit ChatGPT 5.0 mini enthält, wie diesen:

<!-- wp:paragraph -->
<p>
  Pédagogie: 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><strong><br></strong>Support : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Coûts : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Débouchés : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark>
</p>
<!-- /wp:paragraph -->

...könnte die Antwort ein zusätzliches <mark>-Tag einführen, das im ursprünglichen Inhalt nicht vorhanden war:

<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★
+<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">

Beim Bearbeiten des Beitrags im WordPress-Editor kann dieser Block möglicherweise nicht gerendert werden und stattdessen die Meldung "Block contains unexpected or invalid content" anzeigen:

Beschädigter Block mit der Meldung zu ungültigem Inhalt
Beschädigter Block mit der Meldung zu ungültigem Inhalt

Ein Klick auf Attempt recovery wird das Problem höchstwahrscheinlich lösen.

Vermeide wenn möglich die Verwendung von HTML-Blöcken, da der gesamte HTML-Blob als eine einzelne Einheit übersetzt werden muss.

Verwende stattdessen benutzerdefinierte Blöcke mit Eigenschaften, damit diese übersetzbaren Zeichenketten identifiziert, extrahiert und übersetzt werden können, ohne die Formatierung zu beschädigen.

Fehler durch beschädigte Daten beheben

Gelegentlich können während der Übersetzung Fehler auftreten, weil dein Inhalt beschädigte oder veraltete Daten enthält. Das geschieht typischerweise wenn:

  • Ein Beitragstyp früher eine Funktion unterstützte (wie übergeordnete Beiträge), dies aber nicht mehr tut
  • Inhalt referenziert Entitäten, die nicht mehr existieren
  • Datenbankinkonsistenzen durch Migrationen oder Plugin-Änderungen
  • Verwaiste Beziehungen in benutzerdefinierten Feldern

Den Fehler verstehen:

Wenn du in den Protokollen einen Fehler wie diesen siehst:

2025-10-25T03:40:38+00:00 Error [Query "create-missing-translation-media"] Execution with errors: 🔴 Object with ID '26061' (of type 'GenericCustomPost') cannot be loaded. Please check if referencing this ID is stale data (i.e. still stored on the WordPress database, but pointing to a non-existing object) and, if so, remove it or fix it.

Das bedeutet:

  • Der Inhalt referenziert eine Entität (Beitrag, Seite, Medium usw.) mit der ID 26061
  • Diese Entität existiert nicht mehr in der Datenbank
  • Das Plugin kann nicht übersetzen, weil es die Referenz nicht auflösen kann

Wie man das behebt:

Methode 1: WordPress-Editor (einfachste Methode)

  1. Öffne den Beitrag/das Element, bei dem die Übersetzung fehlschlägt
  2. Identifiziere die beschädigte Referenz (prüfe benutzerdefinierte Felder, Beziehungen usw.)
  3. Entferne oder korrigiere die Referenz
  4. Speichere den Beitrag
  5. Versuche erneut zu übersetzen

Methode 2: Datenbankbereinigung

Wenn du es nicht über den Editor beheben kannst:

  1. Identifiziere, welches Feld die fehlerhafte Referenz enthält
  2. Verwende ein Datenbankwerkzeug oder Plugin, um die veralteten Daten zu entfernen
  3. Vorsicht — erstelle immer ein Backup, bevor du Datenbankänderungen vornimmst

Methode 3: Gato GraphQL (fortgeschritten)

Da Gato AI Translations for Polylang Gato GraphQL im Hintergrund verwendet, kannst du GraphQL-Queries ausführen, um beschädigte Daten programmatisch zu beheben:

  1. Rufe zuerst die IDs der Elemente mit Problemen über eine GraphQL-Query ab.

  2. Behebe dann das Problem über eine Mutation. Zum Beispiel, um eine übergeordnete Referenz von einem Medienelement zu entfernen:

mutation {
  updateMediaItem( input: { id: 26066, customPostID: null } ) {
    status
    errors {
      __typename
      ...on GenericErrorPayload {
        message
      }
    }
  }
}

Falls du es nicht beheben kannst:

Wenn die beschädigten Daten nicht bereinigt werden können, musst du möglicherweise:

  • Den Beitrag/das Element von Grund auf neu erstellen
  • Inhalte exportieren, bereinigen und erneut importieren
  • Den Support für Hilfe bei komplexen Fällen kontaktieren

Übersetzte Einträge in die Konfiguration integrieren

Nach der Übersetzung deiner Inhalte müssen die neu erstellten übersetzten Einträge möglicherweise in die Website-Konfiguration integriert werden.

ACF-Field-Groups aktualisieren

ACF-Field-Groups können bestimmten Beiträgen, Seiten, Kategorien, Tags oder anderen Entitäten zugewiesen werden. Wenn du Inhalte übersetzt, müssen die übersetzten Versionen möglicherweise auch denselben Field Groups zugewiesen werden.

Nach der Übersetzung aktualisiere deine ACF-Field-Group-Zuweisungen, um die übersetzten Versionen einzuschließen:

  1. Gehe zum Menüelement Field Groups im ACF-Plugin-Menü
  2. Bearbeite die Field Group, die auf bestimmte Entitäten angewendet wird
  3. Füge in den Location Rules die übersetzten Versionen hinzu
  4. Speichere die Field Group

Beispiel:

Eine Field Group gilt für den spezifischen Beitrag "Hello World" in der Ursprungssprache:

ACF-Field-Group vor dem Hinzufügen von Übersetzungen
ACF-Field-Group vor dem Hinzufügen von Übersetzungen - gilt nur für den Originalbeitrag

Nach der Übersetzung des Beitrags müssen auch die übersetzten Versionen ("Hola Mundo" auf Spanisch und "你好世界" auf Chinesisch) derselben Field Group zugewiesen werden:

ACF-Field-Group nach dem Hinzufügen von Übersetzungen
ACF-Field-Group nach dem Hinzufügen von Übersetzungen - gilt für alle Sprachversionen

Das war's!

Du hast jetzt den Übersetzungsprozess abgeschlossen. Herzlichen Glückwunsch! 👏

Fazit

Dieser umfassende Leitfaden sollte dir helfen, deine WordPress-Website erfolgreich zu übersetzen. Wenn du weitere Informationen benötigst, sieh dir die Dokumentation zu Gato AI Translations for Polylang an.


Erfahre, was als Nächstes kommt

Abonniere unseren Newsletter: Erfahre, wenn wir eine neue Version veröffentlichen, ein neues Plugin starten oder Neuigkeiten mit dir teilen.