Elementor- & Divi-Vorlagen übersetzen, ohne Layouts zu beschädigen

Sie haben alles richtig gemacht. Sie haben ein Premium-Theme gekauft, die .po-Datei gefunden, sie sorgfältig übersetzt und die .mo-Datei in Ihren Sprachenordner hochgeladen. Zeichenketten im Theme-Header werden korrekt aktualisiert. Der Footer wird auf Spanisch angezeigt. Ihr WooCommerce-Checkout ist lokalisiert. Doch dann öffnen Sie die Startseite, und jede Überschrift, jeder Button und jeder Textblock, der mit Elementor erstellt wurde, ist immer noch auf Englisch.

Sie überprüfen die .po-Datei. Sie sehen die englischen Zeichenketten im Code. Sie übersetzen erneut. Nichts ändert sich. Sie leeren Caches. Nichts ändert sich. Sie reden sich ein, dass etwas kaputt ist, bis jemand in einem Forum behutsam darauf hinweist: Elementor (und Divi, und Beaver Builder, und Bricks) speichern Inhalte nicht in .po-Dateien. Das war nie der Fall. Sie haben ein Problem bekämpft, das mit dem von Ihnen verwendeten Ansatz nicht lösbar ist.

Dieser Leitfaden erklärt, warum Page Builder-Inhalte architektonisch anders sind als Theme- und Plugin-Inhalte, die zwei Wege, sie zu übersetzen, und wie Widget-Markup während der Übersetzung intakt bleibt, damit Ihre sorgfältig gestalteten Layouts nicht auseinanderfallen.

Warum Elementor und Divi keine .po-Dateien verwenden

.po-Dateien speichern Zeichenketten, die im Code leben – __( 'Shop', 'mytheme' )-Aufrufe, die über PHP-Templates verteilt sind. Das Build-Tool WP-CLI kann diese Zeichenketten in ein .pot-Template extrahieren, Übersetzer arbeiten mit .po-Dateien, und kompilierte .mo-Dateien werden zur Laufzeit geladen.

Page Builder-Inhalte sind anders. Wenn Sie „Willkommen in unserem Shop“ in ein Elementor-Überschriften-Widget eingeben, befindet sich dieser Text in keiner PHP-Datei. Er wird als JSON (Elementor) oder als Shortcode-Block (Divi) in der Tabelle wp_postmeta gespeichert, verknüpft mit dem Beitrag, in dem Sie ihn platziert haben.

Wo Page Builder-Inhalte tatsächlich leben

Elementor speichert den Widget-Baum jeder Seite in den Postmeta unter dem Schlüssel _elementor_data. Öffnen Sie einen beliebigen Beitrag in der Datenbank und Sie finden ein JSON-Array, das jeden Abschnitt, jede Spalte und jedes Widget beschreibt, mit Einstellungen und Inhalten inline:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi speichert seine Seiteninhalte als Shortcodes, die in post_content eingebettet sind:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder und Oxygen folgen dem gleichen Muster mit ihrem eigenen Format. Keiner dieser Inhalte wird jemals von .po- / .mo-Dateien berührt.

Was sich wirklich in .po-Dateien befindet

Das Page Builder-Plugin selbst enthält UI-Zeichenketten – Schaltflächenbeschriftungen im Editor, Fehlermeldungen, Admin-Hinweise. Diese befinden sich in .po-Dateien und werden von Ihren .mo-Dateien in wp-content/languages/plugins/ übersetzt. Das ist normalerweise der Grund, warum Menschen verwirrt sind: Sie übersetzen „Elementor“-Zeichenketten und sehen die Editor-Benutzeroberfläche auf Spanisch, aber der tatsächliche Inhalt, den sie mit diesen Widgets erstellt haben, bleibt auf Englisch.

Diese Unterscheidung ist auch die Ursache für die Hälfte der Tickets in unserem Fehlerbehebungsleitfaden für nicht angezeigte Übersetzungen – der Leser erwartet, dass .mo-Dateien den Inhalt beeinflussen, den er im Frontend sieht, aber der Inhalt befindet sich in der Datenbank, nicht im Code.

Was .po-Dateien auf einer Page-Builder-Website tatsächlich abdecken

Lassen Sie mich eine klare Abgrenzung zwischen den beiden ziehen, damit Sie genau wissen, was jeder Dateityp handhabt.

.po- / .mo-Dateien übersetzen

• Die Template-Zeichenketten des Themes: get_template_part, fest codierter Text in header.php, footer.php, functions.php.
• Plugin-UI-Zeichenketten: WooCommerce-Checkout, Yoast-Admin-Labels, Contact Form 7-Feld-Labels.
• Page Builder Plugin-UI: Elementor-Editor-Buttons, Divi-Speicherbestätigungen.
• Dynamische Zeichenketten, die Plugins im Frontend ausgeben: WooCommerce „In den Warenkorb“, „Nicht auf Lager“, Warenkorbsummen.

.po- / .mo-Dateien übersetzen NICHT

• Überschriften-, Absatz-, Button-Text, der in Elementor-Widgets eingegeben wird.
• Bildunterschriften, Hover-Effekte, Akkordeon-Titel innerhalb von Divi-Modulen.
• Inhalte in wiederverwendbaren Templates, globalen Abschnitten, gespeicherten Blöcken.
• Benutzerdefinierte CSS-Labels oder Inline-Skripte innerhalb von Builder-Widgets.

Dies ist der Grund, warum die Dokumentation der Theme-Autoren zur Übersetzung technisch korrekt, aber für Endbenutzer oft nutzlos ist. Unser Leitfaden „So lokalisieren Sie jedes WordPress-Theme, auch wenn Sie kein Entwickler sind“ behandelt die Theme-Seite gründlich – dieser Beitrag knüpft dort an, wo jener endet.

Zwei Wege zur Lokalisierung von Page Builder-Inhalten

Es gibt genau zwei Wege, Page Builder-Inhalte zu übersetzen, und beide haben echte Kompromisse.

Weg Eins: Seiten pro Sprache duplizieren

Verwenden Sie ein mehrsprachiges Plugin wie WPML, Polylang oder TranslatePress. Es erstellt eine Kopie jeder Seite pro Sprache. In Elementor duplizieren Sie das gesamte Layout und tauschen den Text auf jeder Kopie aus. In Divi kopieren Sie den Shortcode-Block und übersetzen den Text zwischen den Tags.

Pros: Jede Sprache kann unabhängig gestaltete Layouts haben (nützlich, wenn übersetzter Text länger ist und Ihr ursprüngliches Design sprengt). Volle Kompatibilität mit dem visuellen Editor des Page Builders.

Cons: Lineare Skalierung – 5 Sprachen bedeuten 5-fachen Layout-Aufwand. Jede Designänderung muss 5-mal angewendet werden. Datenbank wächst schnell. Caching wird schwieriger.

Weg Zwei: String-Übersetzungsebene

Einige Plugins (Polylang Pro, WPMLs String Translation-Modul, TranslatePress) können einzelne Zeichenketten innerhalb von Page Builder-Widgets zur Übersetzung verfügbar machen und diese dann zur Renderzeit austauschen. Sie pflegen ein Layout und das Plugin übersetzt die Zeichenketten direkt.

Pros: Eine einzige Quelle der Wahrheit für das Layout. Designänderungen werden überall angewendet.

Cons: Geringere Flexibilität, wenn übersetzter Text die Länge drastisch ändert. Einige Widgets (komplexe mit verschachtelten Inhalten, dynamische Listen, Formulare) legen Zeichenketten nicht sauber offen. Performance-Kosten pro Render.

Unser Polylang vs. WPML vs. TranslatePress Vergleich behandelt die Kompromisse jedes Plugins detaillierter.

Widget-Markup während der Übersetzung sicher halten

Welchen Weg Sie auch wählen, übersetzte Inhalte müssen das strukturelle Markup des Builders bewahren. Wenn Ihr Übersetzer einen Elementor-Shortcode entfernt, ein Datenattribut ersetzt oder verschachtelte Tags neu anordnet, wird das Widget fehlerhaft dargestellt.

Elementor Gefahrenzonen

Elementor-Widgets betten Shortcodes und dynamische Tags in Texteinstellungen ein. Das Titelfeld eines Überschriften-Widgets kann enthalten:

Welcome to <strong>our</strong> [user_name] store

Das [user_name] ist ein dynamisches Tag – Elementor ersetzt es zur Renderzeit durch den Namen des angemeldeten Benutzers. Wenn die Übersetzung es verfälscht, wird den Benutzern buchstäblich „[user_name]“ angezeigt.

Icons in Buttons verwenden Klassenattribute, die nicht übersetzt werden dürfen. Der Alt-Text von Bildern wird separat von der Bild-URL gespeichert. Spaltenlayouts verwenden breakpoint-spezifische Einstellungen (title_mobile, title_tablet), die eine individuelle Behandlung erfordern.

Divi Shortcode-Verschachtelung

Divi-Shortcodes verschachteln sich tief: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Ein Übersetzer, der den Block als Klartext behandelt, wird eckige Klammern kodieren, Attributwerte übersetzen oder schließende Tags verlieren. Jedes davon beschädigt das Modul und Divi weigert sich, es darzustellen.

Das sichere Muster

Für beide Builder gilt: Die Übersetzung muss:

1. Das Widget-Format parsen (JSON für Elementor, Shortcode-AST für Divi).
2. Den Baum durchlaufen und nur die für den Benutzer sichtbaren Textfelder identifizieren.
3. Shortcodes, dynamische Tags, HTML-Attribute und Inline-CSS sperren.
4. Nur die Textoberflächen mit Kontext an den Übersetzer senden.
5. Übersetzten Text in die ursprüngliche Struktur wieder einfügen.

Dies ist dasselbe Prinzip, das unsere Engine auf .po-Dateien anwendet. Der Leitfaden zum Übersetzen von .po-Dateien ohne das Brechen von Codevariablen erläutert die %s- und Platzhalter-Muster detailliert – das Äquivalent für Page Builder sind Shortcodes und dynamische Tags.

Ein hybrider Workflow, der tatsächlich funktioniert

Für die meisten Teams ist die praktische Antwort eine Kombination beider Ansätze.

Schritt 1: Theme- und Plugin-UI über .po-Dateien übersetzen

Exportieren Sie .pot-Dateien von Ihrem Theme und wichtigen Plugins (WooCommerce, Yoast, Page Builder UI). Übersetzen Sie sie einmal über einen Cloud-Übersetzer, der das .po-Format respektiert. Legen Sie kompilierte .mo-Dateien in wp-content/languages/ ab. Dies deckt 80% der Interface-Zeichenketten Ihrer Website mit nahezu keinem laufenden Wartungsaufwand ab.

Schritt 2: Ein mehrsprachiges Plugin für dynamische Inhalte auswählen

Installieren Sie Polylang oder WPML für Beitrags-, Seiten- und Produktinhalte. Konfigurieren Sie die URL-Struktur (/es/, /fr/) und hreflang-Tags. Dies gibt Ihnen die Infrastruktur für datenbankbasierte Inhalte pro Sprache.

Schritt 3: Ihre Page Builder-Vorlagen selektiv duplizieren

Für stark frequentierte Landing Pages, Startseiten und zentrale Marketing-Inhalte duplizieren Sie die Seite in jeder Sprache und übersetzen die Widgets manuell. Sie erhalten die volle Designkontrolle dort, wo es darauf ankommt.

Schritt 4: String-Übersetzung für wiederholte Blöcke verwenden

Für globale Abschnitte, wiederverwendbare Templates und Footer-CTAs, die auf jeder Seite erscheinen, verwenden Sie die String-Übersetzungsfunktion Ihres mehrsprachigen Plugins. An einem Ort aktualisieren, zur Renderzeit austauschen.

Schritt 5: Qualitätsprüfungen durchführen

Übersetzte Page Builder-Inhalte sollten ohne Layout-Verschiebungen gerendert werden. Längere Sprachen (Deutsch, Russisch) sprengen Button-Breiten. Kürzere Sprachen (Chinesisch, Japanisch) hinterlassen unpassende Leerzeichen. Testen Sie jedes Template pro Sprache vor der Veröffentlichung.

Häufige Fallstricke und wie man sie vermeidet

Einige Fallen, die in jedem Page Builder-Lokalisierungsprojekt auftreten.

Alt-Text von Bildern wird nicht übersetzt

Sowohl Elementor als auch Divi speichern den Alt-Text pro Widget-Instanz, nicht in der Mediathek. Das Übersetzen des Originalbildes übersetzt nicht den Alt-Text in jedem Widget, das es verwendet. Aktualisieren Sie den Alt-Text auf jeder duplizierten Seite.

Formulare und benutzerdefinierte Felder

Kontaktformulare, die in Page Builder-Widgets eingebettet sind, haben ihre eigenen Zeichenketten (Labels, Platzhalter, Validierungsmeldungen). Lesen Sie unseren Leitfaden zum Übersetzen von Gravity Forms und Contact Form 7 für die Formularseite.

Globale Widgets und Templates

Änderungen an einem globalen Template verbreiten sich auf jede Seite, die es verwendet, einschließlich übersetzter Kopien. Dies kann nützlich oder katastrophal sein, je nachdem, ob Sie geteilte oder separate Inhalte wünschen. Entscheiden Sie dies explizit pro Template.

Ablauf des Übersetzungscaches

Page Builder cachen gerendertes HTML aggressiv. Leeren Sie nach der Übersetzung alle Caches, einschließlich des Elementor CSS-Caches (Elementor > Tools > Regenerate CSS) und des Divi statischen CSS-Caches.

Zusammenfassung

Eine mit Elementor oder Divi erstellte Website zu übersetzen, ist nicht schwieriger als das Übersetzen eines statischen Themes – es erfordert lediglich das richtige Denkmodell. Theme- und Plugin-Zeichenketten leben in .po-Dateien und werden über .mo-Dateien transportiert. Page Builder-Inhalte leben in der Datenbank und werden über mehrsprachige Plugins oder manuelle Duplizierung transportiert. Das Verwechseln der beiden Wege ist die häufigste Ursache für die Frustration „Warum funktionieren meine Übersetzungen nicht?“.

Der erfolgreiche Workflow ist unspektakulär: statische .mo-Dateien für alles, was im Code lebt, ein mehrsprachiges Plugin für Seiteninhalte und manuelle Kuration für hochwertige Landing Pages. Kein einziges Tool deckt alle drei ab, und wer Ihnen etwas anderes verspricht, versucht Ihnen etwas zu verkaufen.

Bereit, Ihre Theme- und Plugin-.po-Dateien zu übersetzen, ohne das Widget-Markup zu beschädigen? Testen Sie SimplePoTranslate kostenlos – keine Kreditkarte erforderlich. .po hochladen, sichere Übersetzungen herunterladen, in wp-content/languages/ ablegen.