WordPress und Mehrsprachigkeit – keine gute Idee

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 6 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet ...

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.

24 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!

  7. Hallo Zusammen,
    bin gerade über diesen Artikel gestolpert, da ich auf meiner WordPress Seite deutsch als 2. Sprache anbieten möchte. Ich habe Polylang auf einer Testversion ausprobiert und fand es soweit ok. Jetzt ist mir allerdings aufgefallen, dass ich fürs SEO keine Möglichkeit habe dies auch auf deutsch anzupassen. Ich nutze Yoast SEO Premium. Hat hier jemand Erfahrung und kann mir Tipps geben, was das beste Plugin wäre. Ich werde definitiv nur bei 2 Sprachen beleiben. Danke und viele Grüsse, Betty

  8. Moin zusammen,
    ich möchte meine Internetseite auch englischsprachiger Kundschaft in meiner Stadt anbieten. Würde es eventuell Sinn ergeben, einfach eine komplett neue Seite mit englischem URL und neuer SEO zu erstellen?
    Danke und ein frohes neues Jahr 🙂
    Ralf

  9. Hallo Thorsten,

    ich finde diesen Artikel hast du einfach nur grandios geschrieben. Das trifft den Nagel auf den Kopf. Die derzeit verfügbaren „Lösungen“ sind einfach nervig und kompliziert.

    Beste Grüße aus Hannover

    Pattrick

  10. Hallo zusammen,
    hat hier jemand Erfahrungen mit Neuronto https://t3n.de/news/neuronto-wordpress-plugin-deepl-1189089/ gemacht ? Soll angeblich die Schnittstelle von DeepL nutzen und im Vergleichstest war die Qualität viel besser als bei einem automatischen WP Google Übersetzer.

    LG
    KRis

  11. Hi,

    DEEPL ist an und für sich super hilfreich beim übersetzen von Texten.

    Eine automatisch übersetzte Webseite würde ich dir jedoch nie empfehlen.

    • Dem kann ich nur zustimmen. DeepL ist sicher aktuell der beste Übersetzer (besser als Google Translate), aber es ist und bleibt ein Werkzeug für Übersetzer und ist kein Allheilmittel. Insbesondere, wenn nicht beide Sprachen beherrscht werden, kann es zu schwerwiegenden Fehlern kommen, die ich niemals auf einer Live-Website haben wollen würde.
      Siehe auch diesen Artikel: https://dvud.de/2018/05/deepl-der-schein-truegt/

  12. Hallo Torsten,
    es scheint so, als ob Du Dich auskennst.

    ich habe gerade eine Weile gesucht, aber nicht das passende für mich gefunden:

    Ich baue gerade eine Seite auf, auf der einzelne, nicht ALLE Seiten mehrsprachig sein sollen. Habe gerade Polylang ausprobiert, was mit im Backend auch gut gefällt, allerdings scheint das Plugin davon auszugehen, dass die komplette Seite mehrsprachig wird, mit eigenem Navibaum usw.

    Das ist für mich eher hinderlich, ich brauche nur ein paar Seiten im Angebot, die mehrsprachig sind. Ich habe kein Plugin gefunden, wo das ein Feature ist – kennst Du eins?

    Oder würdest Du hier eher den Weg „zu Fuß“ gehen und einen Bereicht mit ein Seiten in EN anlegen – und dann irgenwie eine Sprachwechlser manuell mit Hin- und Her-Verlinkungen bauen?

    Freue mich über eine Einschätzung. Viele Grüße. Stephan

    • > allerdings scheint das Plugin davon auszugehen, dass die komplette Seite mehrsprachig wird, mit eigenem Navibaum

      Kann dir da nicht ganz folgen, was du mit eigenem Navibaum meinst. Wenn es zu einer Seite keine Übersetzung gibt, dann wird der Sprachwechsler einfach nicht angezeigt (bzw. führt die entsprechende Sprache nicht auf).

      Das Ganze manuell zu bauen geht natürlich auch, aber wenn die Site dann auch korrekt die Sprache anzeigen soll (lang Attribut, etc.), dann ist Handarbeit gefragt.

      Ich würde den Weg mit Polylang noch weiter testen. Wäre auf jeden Fall mein erste Wahl bei den gegebenen Informationen.

      • Oh – ich denke, da war ich zu tief in meinem Nerd-Dasein drin…

        Also – ich habe folgende Situation:
        Ich habe eine Seite mit über 100 Unterseiten.
        ca. 10 davon (Impressum, Über Uns usw.) sollen in EN sein – der Rest nicht.

        Wenn ich es richtig sehe, wird in der Navigation, wenn ich in EN bin, die Navigation nur über die 10 Seiten angezeigt – ist das so? Ich hatte den Eindruck, wenn ich dann im EN-Bereich bin, wirkt die Navigation kaputt und der User ist lost – da er dann nicht mehr erkennt, wie umfangreich die Seite eigentich ist..

        Sorry – und ich hoffe, das wird jetzt klarer, was meine Absicht ist.

  13. In jeder Sprache werden nur die Menüeinträge angezeigt, die du im jeweiligen Menü hast. Ja die Seite wird dann nur über 10 Seiten angezeigt, wenn du nur diese 10 Seiten übersetzt hast und Menüeinträge kreiert hast. Und lost wäre er ja nur wenn er hunderte Menüeinträge sehen würde, die nicht funktionieren oder auf die Deutsche Seite verlinken… Und wenn du auf Englisch eben nur 10 Seiten hast, dann ist dies der Umfang der auf englisch zur Verfügung steht 🙂

Schreibe einen Kommentar

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