WordPress und Mehrsprachigkeit – keine gute Idee

Was gibt es für Möglichkeiten eine WordPress-Website mehrsprachig zu machen? Da gibt es maschinelle Übersetzungen durch Drittanbieter, Übersetzungsplugins und die Multisite-Lösung. Alle Varianten kranken jedoch an einer gemeinsamen Sache. Sie sind Krücken und Flickschusterei. Ein Armutszeugnis für ein Tool, welches sich Übersetzbarkeit in die Philosophie schreibt, aber kein Core-Werkzeug für seine Benutzer anbietet.

Schauen wir uns Variante 1 an: Maschinelle Übersetzung

Die Qualität dieser Übersetzungen ist in den letzten Jahren enorm gestiegen. Keine Frage. Aber ein ernsthafter Ersatz für eine professionelle Übersetzung ist das sicher nicht. Dafür ist Sprache zu kompliziert, ebenso die möglichen Inhalte von Websites. Das mag für eine Visitenkarte mit begrenztem Vokabular noch funktionieren, aber längere Texte mit nicht näher spezifizierten Inhalten sind kaum sinnvoll zu übersetzen. Auch wenn viele der Übersetzungsplugins nur solche Dienste einbinden.

Bleibt Variante 2: Der Plugin-Weg

Ja, es gibt WPML (kostenpflichtig) oder Polylang, aber alle Plugins dieser Art kranken am User Interface. Sie müssen die zusätzlichen Felder für Übersetzungen irgendwie in das eh schon überfüllte Backend einfügen. Spätestens bei mehr als 10 Sprachen ist das so überfrachtet, dass dies kaum noch übersichtlich ist.

Spannend bei diesen Plugins ist vor auch, was passiert, wenn das Plugin deaktiviert wird. qTranslate bzw. qTranslate-X war da problematisch und alle die auf dieses Pferd gesetzt haben, haben nun ein Problem, denn so wie es aussieht ist die Entwicklung eingestellt.

Ein zusätzliches Problem ist, dass diese Plugins nur für den Core ausgerichtet sind. Plugins, die Nacharbeit erfordern, wie zum Beispiel WooCommerce, benötigen Zusatzplugins (z.T. kostenpflichtig), um komplett übersetzt zu werden.

Kommen wir zu Variante 3: Multisite

Der Multisite-Ansatz löst schon viele der eben beschriebenen Probleme. Durch die Aufteilung auf einzelne Sites haben wir kein UI-Problem. Nach dem Deaktivieren eines ggf. genutzten Plugins bleiben vollständig intakte Sites in der jeweiligen Sprache zurück und auch große Plugin-Boliden wie WooCommerce können normal und in der jeweiligen Sprache eigenständig konfiguriert werden. Für die Verknüpfung der Beiträge und Seiten gibt es Plugins wie Multilingual Press oder den Multisite Language Switcher.

Hier enden jedoch auch schnell die Vorteile und die Kehrseite diese Eigenständigkeit macht sich bemerkbar. Da die Multisite ursprünglich nicht für diesen Zweck gedacht war, macht die Standardfunktionsweise immer wieder Probleme. So können zwar individuelle Bilder genutzt werden, aber sofern Bilder identisch sein sollen, müssen Sie auch mehrfach hochgeladen werden. Oder man behilft sich mit einem Plugin wie Network Shared Media.

Ein Shop wie WooCommerce kann komplett individuell eingerichtet werden, was aber auch bedeutet, dass es keine Verknüpfung der Warenkörbe gibt. Und somit auch keinen gemeinsamen Warenbestand. Außer es gibt eine Synchronisierung mit einem externem System über die verschiedenen Shops.

Für Anfänger dürfte aber auch schon die 4-Zeichen-Erfordernis ein unüberwindbares Hindernis darstellen. Das ist zwar leicht gelöst mit einem mu-plugin wie diesem hier:

function custom_hook( $length ) {
	return 2;
}
add_filter( 'minimum_site_name_length', 'custom_hook' );

Aber es ist nervig …

Auch die Unfähigkeit von WordPress eine Single-Installation nach längerer Zeit auf eine Subfolder-Multisite umzustellen ist eine echte Einschränkung. Das Hinzufügen des "/blog"-Zusatz beim Permalink im Blog ist auch so ein Nerv, den man erst entfernen muss.

Plugins können außerdem immer zusätzliche Probleme bereiten. Sie können nicht für den Einsatz in der Multisite vorbereitet sein. Es kann lizenzrechtlich nicht erlaubt oder teurer sein, sie in der Multisite einzusetzen. Oder sie speichern (gewollt) ihre Daten in jeder einzelnen Site-Instanz ab, was aber nicht immer gewollt sein muss. Mein Standard-Beispiel an dieser Stelle ist immer der Booking-Kalender für das Ferienhaus. Sofern das Booking-Plugin die Daten pro Site speichert, ich aber nur ein Ferienhaus mehrsprachig anbieten will, habe ich ein Problem.

Fazit

Meines Erachtens wäre eine bessere Core-Lösung dringend notwendig. Zusätzlich könnte bei jedem Plugin noch als Info stehen, ob es Multisite-kompatibel ist. In jedem Fall ist die Einrichtung viel zu kompliziert, erfordert zu viele Schritte und birgt Fallstricke, die schnell zum Abbruch und zur Frustration führen können.

14 Antworten auf WordPress und Mehrsprachigkeit – keine gute Idee

  1. Hallo Torsten, danke für deinen Artikel, sehr interessant. Was ist denn aber jetzt deine Empfehlung für z.B. eine Unternehmensseite mit 6 Sprachen? Auf eine bessere Core Lösung zu warten ist ja keine Option.

    • Kommt darauf an, um was für ein Projekt es sich handelt und wie viele individuelle Anpassungen nötig sind. Je individueller die Seiten sein müssen, desto besser ist Multisite geeignet. Bei kleinen Projekten (oder wenn Multisite aus anderen Gründen ausfällt) wäre Polylang meine erste Wahl. Warten auf eine Core-Lösung ist aussichtslos.

  2. Moin moin – wir arbeiten schon viele Jahre mit WPML und sind (den Umständen entsprechend) recht zufrieden mit der Lösung. WPML ist zwar kostenpflichtig aber recht intuitiv zu nutzen und hat nur selten nach Updates zu Fehlern geführt; es wird etwas komplizierter, wenn die Website individueller aufgebaut ist (eigene Theme/Widgets/Plugins beispielsweise); aber wenn man schon Individualentwicklung betreibt, sollten dann weitere Anpassungen für zusätzliche Sprachen für diese Elemente auch noch drin sein. Außerdem beinhaltet WPML einige Erweiterungen für WooCommerce, Page Builder oder Gravity Forms. Ich glaube, diese Erweiterungen sind das Plus von WPML gegenüber Polylang – ich gebe zu, ich kenne Polylang nur sehr oberflächlich.
    Multisite ist m. E. für kleinere Projekte viel zu anstrengend einzusetzen – Multisite macht nur Sinn wenn (getrennte) Teams mit festgelegten Workflows zusammenarbeiten, sonst kann man gleich eigene Websites pro Sprache erstellen…
    Eine Core Lösung (etwa wie bei TYPO3) wäre wohl das Beste – aber wie du es selbst schreibst, wird sie beim nächsten Release nicht dabei sein, beim übernächsten auch nicht, usw.. 😉
    PS: das maschinelle Übersetzen ist m. E. nicht wirklich erwähnenswert. Kann man mal nutzen wenn man bei einer Recherche eine Website in einer fremden Sprache findet und schnell mal verstehen möchte, aber als Betreiber einer Website sollten die Ansprüche doch größer sein – und das Wording für eigene Inhalte nicht anderen überlassen…

    • WPML hat immer wieder Kompatibilitätsprobleme mit Themes/Plugins und ist meines Erachtens immer ein Performance-Killer. Was das deine Erfahrungen?
      Polylang hat eine Pro-Version und eine WooCommerce-Erweiterung und einen WPML-Importer, für Wechsler … da lohnt sich ein zweiter Blick bestimmt.
      Aber es stimmt total, dass die Zielgruppe für Multisite eigentlich (trotz des besten Ansatzes) sehr klein ist. Häufig könnte man auch einfach einzelne Sites bauen.
      Core-Lösung kommt schon mal nicht 2018 (da geht es ja ausschließlich um Gutenberg), daher würde ich darauf nicht warten. Das habe ich jetzt 4 Jahre gemacht. Da kommt so schnell nichts. Neben Typo3 hat Drupal auch eine Core-Multilanguage-Lösung, oder?
      Ja, maschinelle Übersetzungen habe ich nur der Vollständigkeit halber erwähnt. Mein Fazit ist ja ähnlich …

  3. Danke Thorsten, ich habe früher polylang und jetzt öfter wpml genutzt, da es teilweise eine bessere Kompatibilität mit Themes hat. Eine Core Lösung wäre erstrebenswert, da gebe ich dir recht. Gibt es da irgendwelche Bestrebungen?

  4. Und noch ein schönes Beispiel für Multisite-Fuckup. Diesmal mit einem Page Builder:
    https://siteorigin.com/thread/multilingual-press-compatibility/

  5. Hallo,

    Guter Artikel, ich kam gerade auf diesen Artikel, weil ich wieder einmal nachgeschaut ob es mitlerweile interessante Lösungen für Mehrsprachikeit von WP Seiten gibt… Ich musste vor zwei Jahren eine Mehrsprachige WordPress Webseite für einen Kunden erstellen und habe dies schlussendlich nach einigen Tests mit QtranslateX (ohne festes Entwicklerteam keine Sicherheit für die Zukunft), dann mit WPML gemacht, was ich aber als sehr umständlich und kompliziert empfand und auch der Support war fern von ideal. Seitdem lege ich es allen meinen Kunden, die eine Mehrsprachige Webseite mit einem kostenlosen CMS haben wollen, dies mit Joomla zu machen wo die Mehrsprachigkeit im Core vorhanden ist und ich noch wirklich sehr selten Kompatibilitätsprobleme hatte und auch keine Angst für zukünftige Updates haben muss.

  6. Hallo Torsten,

    Vielen Dank für deinen Beitrag!
    Ich habe auch kleine Probleme mit WPML nach Updates.
    Könntest du vielleicht eine Alternative dafür empfehlen?

    Danke im Voraus!

Schreibe einen Kommentar zu Matthias Antwort abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.