WordPress FAQ: Häufige Fragen zu mehrsprachigen Websites

In der Schweiz mit ihren vier Amtssprachen sind mehrsprachige Websites eher die Regel als die Ausnahme. Doch WordPress stammt aus den USA, und die Mehrsprachigkeit wurde ihm nicht in die Wiege gelegt. Wie kann man mit WordPress trotzdem mehrsprachige Websites erstellen? Und was gilt es dabei zu beachten?

Kann man mit WordPress mehrsprachige Websites erstellen?

Ja – allerdings nicht ohne ein entsprechendes Plug-in, denn WordPress ist derzeit nur für einsprachige Websites ausgelegt. Zwar soll im Rahmen des Project Gutenberg die Mehrsprachigkeit im WordPress Core implementiert werden. Aber es gibt derzeit keine konkreten Informationen, wie und bis wann dies geschehen wird. Aufgrund der Äusserungen von Matt Mullenweg am WordCamp Europe 2024 haben die Core-Entwickler wohl andere Prioritäten.

Bis auf weiteres braucht es also für mehrsprachige WordPress-Websites zwingend ein Plug-in, das die Mehrsprachigkeit implementiert. Das ist insofern nicht dramatisch, als es ein breites Angebot an ausgereiften Lösungen gibt. Was es hingegen nicht gibt ist ein Standard, wie Übersetzungen in WordPress verwaltet werden. So hat jedes Mehrsprachigkeits-Plug-in sein eigenes Konzept, und so kommt es immer wieder einmal zu Kompatibilitätsproblemen mit Themes und Plug-ins.

Spielt es eine Rolle, welches Plug-in man für die Mehrsprachigkeit benutzt? Wie gross sind die Unterschiede zwischen den einzelnen Produkten?

Es gibt sehr unterschiedliche Ansätze, wie man eine WordPress-Website mehrsprachig machen kann. Die vier wichtigsten sind:

• 1 Post pro Sprache
  Der gängigste Ansatz besteht darin, dass jeder Post (Seite, Beitrag etc.) ein Sprachkennung erhält und beim Übersetzen jeweils ein neuer Post in der Zielsprache angelegt wird. Das Mehrsprachigkeits-Plug-in sorgt dafür, dass die Übersetzungen mit dem Original-Post verknüpft sind und man leicht zwischen den Sprachversionen wechseln kann. Der Vorteil dieses Ansatzes ist, dass die Sprachversionen nicht zwingend identisch sein müssen, sondern individuelle Inhalte haben können.
• Übersetzungs-Overlay
  Bei dieser Methode werden unmittelbar beim Aufruf einer Seite die Originaltexte durch ihre Übersetzungen ersetzt – so ähnlich, wie man das von der automatischen Übersetzungsfunktion eines Browsers kennt. In diesem Fall existieren die Seiten weiterhin nur in der Originalsprache. Die Übersetzung erfolgt nicht im Block Editor, sondern in einem speziellen Translation Editor. Die Übersetzungen werden häufig auf einer externen Übersetzungsplattform (Translation Proxy) verwaltet.
• Inline-Übersetzungen
  Bei diesem Ansatz werden alle Übersetzungen direkt im Original-Post gespeichert. Das Mehrsprachigkeits-Plug-in sorgt dafür, dass sowohl im Frontend als auch im Backend immer nur die Texte in der vom Benutzer ausgewählten Sprache sichtbar sind.
• 1 Website pro Sprache
  Eine weitere Methode besteht darin, für jede Sprache eine eigenständige Website anzulegen. Die komplette Trennung der Sprachversionen, die man so erreicht, hat allerdings mehr Nachteile als Vorteile. Die bessere Lösung ist eine Multisite-Installation mit einem Mehrsprachigkeits-Plug-in, das Original-Post und Übersetzungen über die einzelnen Sites hinweg verknüpft. Diese Methode ist insbesondere für grössere Websites geeignet, bei der die einzelnen Sprach- bzw. Länderversionen eine gewisse Autonomie brauchen.

Jeder dieser Ansätze hat seine spezifischen Vor- und Nachteile – bei der Erstellung und der späteren Pflege der Website-Inhalte, für die Suchmaschinen-Optimierung sowie bezüglich der Kompatibilität mit anderen Plug-ins. Auch unter den Plug-ins, die ein ähnliches Konzept verfolgen, gibt es im Detail oft grössere Unterschiede bei der Funktionalität und der Kompatibiliät. Deshalb spielt es tatsächlich eine wesentliche Rolle, welches Plug-in man für die Mehrsprachigkeit einsetzt. Dies umso mehr, als ein späterer Wechsel des Plug-ins oft aufwändig ist (siehe unten).

Welches sind die wichtigsten Plug-ins, um die Mehrsprachigkeit nachzurüsten?

Das bekannteste und umfassendste Plug-in in diesem Bereich ist WPML. Es ist mit sehr vielen Page Builders, Themes und Plug-ins kompatibel und unterstützt auch komplexe Übersetzungs-Workflows mit externen Übersetzern. WPML nutzt den Ansatz «1 Post pro Sprache» (siehe oben). Es verfügt über einen klassischen Translation Editor, der nur die Texte in Original- und Zielsprache gegenüberstellt, sodass die Übersetzer nicht im Block Editor oder im Page Builder arbeiten müssen, wenn sie das nicht wollen. Optional kann man Inhalte auch von der künstlichen Intelligenz von OpenAI, DeepL, Google oder Microsoft übersetzen lassen.

Weit verbreitet ist Polylang, das ebenfalls nach dem Prinzip «1 Post pro Sprache» arbeitet. Es bietet zwar deutlich weniger Funktionalität als WPML, ist dadurch aber auch weniger leistungshungrig, was sich positiv auf die Ladezeiten auswirkt. Zudem ist Polylang einfach in der Handhabung und in der Basisversion sogar kostenlos.

Gemessen an der Anzahl der aktiven Installationen ist GTranslate inzwischen ähnlich populär wie Polylang. Allerdings ist der Ansatz völlig anders: Erstens arbeitet GTranslate mit Übersetzungs-Overlays, wobei die Übersetzungen nicht in der WordPress-Datenbank, sondern auf dem GTranslate-Server gespeichert werden. Zweitens steht bei Polylang die manuelle Übersetzung im Vordergrund – eine KI-Übersetzung gibt es nur als zusätzliche Option in der Pro-Version. GTranslation dagegen setzt ganz auf automatisierte Übersetzungen mit Google Translate – auf die Übersetzung Einfluss nehmen kann hier nur in der Bezahlversion. GTranslate ist übrigens nicht WordPress-spezifisch, sondern funktioniert mit jeder Website.

Weglot hat viele Ähnlichkeiten mit GTranslate: Auch hier steht die automatisierte Übersetzung im Vordergrund, allerdings hat man die Wahl zwischen DeepL, Google und Microsoft als Übersetzungdienst. Die Übersetzungen werden ebenfalls nicht in der eigenen WordPress-Datenbank gespeichert, sondern auf einem Translation Proxy, von wo sie dann bei jedem Seitenaufruf geladen werden. Auch Weglot ist keine WordPress-spezifische Lösung, sondern bietet Integrationen für diverse Content-Management-Systeme.

Ein drittes populäres Plug-in für Übersetzungs-Overlays ist TranslatePress. Anders als bei GTranslate und Weglot werden die Übersetzungen aber lokal, d.h. in der WordPress-Datenbank auf dem eigenen Server gespeichert. Als Besonderheit arbeiten die Übersetzer zudem nicht in einem klassischen Translation Editor, sondern direkt im Frontend der Website: Jedes Textelement kann ganz einfach angeklickt und dann übersetzt werden. In der kostenlosen Version des Plug-ins übersetzt man manuell, in der bezahlten Version auch automatisch mit Unterstützung von Google Translate oder DeepL.

Erwähnenswert ist ferner MultilingualPress: Dieses Plug-in nutzt die Multisite-Funktionalität von WordPress und legt für jede Sprache eine eigene Site an. MultilingualPress sorgt dafür, dass sich das Ganze trotzdem wie eine einzige mehrsprachige Website anfühlt und vernünftig bedienen lässt. KI-unterstützte Übersetzungen sind ebenfalls möglich, etwa mit DeepL, OpenAI oder Amazon; anders als bei vielen anderen Lösungen erfolgt die Verrechnung aber nicht über den Plug-in-Anbieter, sondern man hinterlegt seinen eigenen API-Key.

Zu den Plug-ins für Inline-Übersetzungen gehören beispielsweise qTranslate XT oder WP Multilang. Dieser Ansatz ist aber insgesamt weniger verbreitet.

Welches sind die wichtigsten Kritieren, die ich bei der Auswahl eines Mehrsprachigkeits-Plug-ins beachten sollte?

Kompatibilität / Vollständigkeit
Zunächst muss das Plug-in in der Lage sein, wirklich alle Texte einer Website zu übersetzen – und nicht nur die Inhalte von Beiträgen und Seiten. Das ist nicht selbstverständlich: Die meisten Plug-ins und viele Themes speichern ebenfalls Texte in der WordPress-Datenbank, und es ist keineswegs garantiert, dass ein Mehrsprachigkeits-Plug-in auch diese erkennen und übersetzen kann. Insbesondere wenn Sie einen Page Builder wie Elementor, Divi oder Bricks einsetzen, sollten sie prüfen, ob das Plug-in damit kompatibel ist.

Benutzerfreundlichkeit
Eine mehrsprachige Website zu erstellen und zu bewirtschaften ist ein nicht zu unterschätzender Aufwand. Umso wichtiger ist es, dass das Einpflegen von Übersetzungen leicht verständlich und effizient gelöst ist. Hilfreich ist ein Translation Editor, also eine einfache Maske für Übersetzer, in der sie ausschliesslich Texte bearbeiten können: So brauchen Übersetzer keine WordPress-Kenntnisse und können auch nichts kaputtmachen.

Schnittstellen und Workflows
Kleinere Websites werden oft von einer einzigen Person betreut, die Übersetzer:in und Content-Manager:in in Personalunion ist. In diesem Fall braucht es weder Schnittstellen noch Workflows. Grössere Websites hingegen werden meist arbeitsteilig bewirtschaftet: Übersetzungen werden von spezialisierten (oft externen) Übersetzer:innen erstellt und müssen vor der Publikation einen Freigabeprozess durchlaufen. In diesem Fall muss das Plug-in sowohl Schnittstellen zu Übersetzungsplattformen als auch Publikations-Workflows bieten.

Performance
Jedes zusätzliche Plug-in macht eine Website ein Stück komplexer und damit auch langsamer. Wenn bei jedem Seitenaufruf auch noch Übersetzungen geladen werden müssen, dann ist es besonders wichtig, dass das Mehrsprachigkeits-Plug-in effizient programmiert ist und die Ladezeiten nicht wesentlich verschlechtert.

Integration von KI-Systemen
Müssen regelmässig grössere Textmengen übersetzt werden, dann ist die Einbindung eines Übersetzungsdienstes von DeepL, OpenAI oder Google ein grosse Hilfe: So kann man die Texte direkt in WordPress übersetzen lassen und erspart sich das mühsame Copy/Paste.

Verbreitung und Aktualität
Es ist generell eine gute Strategie, auf weit verbreitete Plug-ins zu setzen, die regelmässig aktualisiert werden. Das gilt insbesondere für ein Mehrsprachigkeits-Plug-in, das zentrale Funktionen implementiert und deshalb bei Problem nicht einfach deaktiviert oder ersetzt werden kann (siehe unten).

Kann man ein Mehrsprachigkeits-Plug-in problemlos gegen ein anderes austauschen?

Problemlos ist ein solcher Wechsel nie, aber der Aufwand ist unterschiedlich. Bei einem Wechsel von WPML zu Polylang kann man das Plug-in WPML to Polylang nutzen, um einen grossen Teil der bereits erstellen Übersetzungen hinüberzuretten. Für eine Migration in die umgekehrte Richtung gibt es ebenfalls eine Lösung namens Migrate Polylang to WPML. Bei anderen Mehrsprachigkeits-Plug-ins ist ein Wechsel nicht vorgesehen und verlangt eine Neuübersetzung der gesamten Website (bzw. ein manuelles Kopieren der bestehenden Übersetzungen).

Ich habe alle Beiträge und alle Seiten übersetzt. Trotzdem tauchen auf meiner Website noch vereinzelte englische Texte auf. Warum?

Im Zusammenhang mit Übersetzungen muss man zwischen den Inhalten (Content) und den Systemtexten (Strings) unterscheiden.

Inhalte sind jene Texte, die Content Managers selbst in die Seiten einfügen. Solche Texte muss man logischerweise auch selbst übersetzen. Sie sind aber leicht zugänglich und deshalb unproblematisch.

Systemtexte hingegen kommen aus dem WordPress Core, aus dem Theme oder aus einem Plug-in. Sie wurden von einem Entwickler geschrieben und sind in den Programmcode eingebettet. Solche Systemtexte sind in aller Regel englisch. Wenn man Glück hat, existieren Sprachpakete mit Übersetzungen für die Sprachen der eigenen Website – dann werden diese automatisch installiert und man muss sich um nichts kümmern. Fehlen jedoch die Sprachpakete, dann erscheinen diese Texte weiterhin auf Englisch.

Der WordPress Core ist in rund 200 Sprachversionen verfügbar, aber er ist deswegen längst nicht in allen Sprachen auch durchgängig übersetzt, wie man auf translate.wordpress.org sehen kann. Bei Themes und Plug-ins sind die Übersetzungen meist noch lückenhafter: Selbst bei einem populären Plug-in wie Yoast SEO sind die Übersetzungen nur bei den gängigsten Sprachen einigermassen vollständig.

Kann ich Themes und Plug-ins, die nicht übersetzt sind, selbst übersetzen?

In der Regel kann man fehlende Übersetzungen von Themes und Plug-ins selbst erstellen. Die meisten Mehrsprachigkeits-Plug-ins bieten einen String Editor, der Texte im Programmcode findet und es erlaubt, eine passende Übersetzung zu hinterlegen. Alternativ steht mit LocoTranslate ein umfassendes Werkzeug für Sprachpakete zur Verfügung. Es braucht ein bisschen Einarbeitung, bis man alle Feinheiten der WordPress-Sprachpakete verstanden hat, aber wirklich kompliziert ist es nicht. Gewisse Themes bzw. Plug-ins enthalten allerdings hunderte oder gar tausende Strings – diese vollständig (und korrekt) zu übersetzen kann also etwas Arbeit bedeuten.

Übersetzt man Systemtexte auf diese Weise, dann existieren sie ausschliesslich auf der jeweiligen Website. Wenn es nur um einige wenige Strings geht, ist dagegen nichts einzuwenden. Sobald man allerdings grössere Sprachpakete erstellt, sollte man diese auch der WordPress-Community zur Verfügung stellen. Die Sprachpakete werden auf translate.wordpress.org verwaltet, und man kann dort Strings direkt übersetzen oder bestehende Übersetzungen hochladen. Sobald eine Sprache zu mindestens 90 Prozent übersetzt ist, wird das Sprachpaket automatisch geladen, sobald jemand das Theme bzw. Plug-in aus dem WordPress Repository lädt. Auch Korrekturen und Ergänzungen an den Übersetzungen werden über die Aktualisierungsfunktion auf alle WordPress-Websites verteilt, die das Theme bzw. Plug-in verwenden.

Alles bisher Gesagte funktioniert meistens, aber nicht immer. Wenn der Entwickler seinen Code nicht internationalisiert, d.h. für die Übersetzung vorbereitet hat, kann man auch keine Sprachpakete erstellen und laden. Und bei kommerziellen Themes und Plug-ins, die nicht über das WordPress Repository vertrieben werden, werden auch die Sprachpakete nicht auf translate.wordpress.org verwaltet. Wenn man sich hier an der Übersetzung beteiligen will, muss man die Entwickler direkt kontaktieren.

Warum gibt es bei WordPress fünf verschiedene Varianten der Sprache «Deutsch»? Welche soll ich für meine deutschsprachige Website verwenden?

Wie man auf translate.wordpress.org sehen kann, unterschiedet WordPress zwischen «German», «German (Switzerland)» und «German (Austria)». «German» ist Deutsch, wie es in Deutschland gesprochen und geschrieben wird, die beiden anderen Varianten sind an den Sprachgebrauch in der Schweiz bzw. Österreich angepasst.

Die Unterschiede sind nicht riesig, aber für eine professionelle Website durchaus relevant: Auf einer Schweizer Website möchte man keine «ß», sondern nur «ss» haben, statt «Bundesland» soll in Formularen «Kanton» stehen, und Preise sollen als «CHF 1’234.50» statt «€ 1.234,50» formatiert werden. Für Deutschland und die Schweiz gibt es zusätzlich noch die Untervarianten «formell» (Sie-Form) bzw. «informell» (Du-Form) – für Österreich existiert ausschliesslich die informelle Variante.

Welches Deutsch man für seine Website wählt, hängt also einerseits vom Land, andererseits von der Tonalität ab. Allerdings muss man sich bewusst sein, dass die Übersetzungen nicht in allen fünf Varianten gleich vollständig sind. «Deutsch» (also Deutsch für Deutschland in der Du-Form) wird in der Regel zuerst übersetzt und ist deshalb am vollständigsten. Falls also die oben geschilderten Nuancen keine Rolle spielen, fährt man mit dieser Variante am besten.

Falls man hingegen eine andere Variante bevorzugt, ist das Plug-in Preferred Languages hilfreich, das Fallback-Sprachen implementiert. Damit kann man eine Website für «Deutsch (Schweiz)» konfigurieren und trotzdem sicherstellen, dass die Übersetzungen von «Deutsch (Sie)» oder «Deutsch» geladen werden, falls einzelne Strings nicht für «Deutsch (Schweiz)» übersetzt sind.

Was bedeuten Codes wie z.B. en_GB?

Ein solcher Code steht für eine Sprache, genauer für die Sprachvariante eines bestimmten Landes. Die Kleinbuchstaben kennzeichnen die Sprache, die Grossbuchstaben das Land. en_GB steht also für Englisch, wie es in Grossbritannien genutzt wird. Beim Deutschen unterscheidet man typischerweise die Varianten de_DE (Deutschland), de_CH (Schweiz) und de_AT (Österreich).

Sowohl die Sprachcodes als auch die Ländercodes sind von der ISO normiert.

Welche Ansätze gibt es, um bei einer mehrsprachigen Website die URLs zu konfigurieren?

Im wesentlichen gibt es drei verschiedene Methoden, um mehrere Sprachversionen einer Website zu adressieren: über Subdomains, über Unterverzeichnisse oder über den Query String.

Die klarste Trennung erreicht man, wenn man je eine Subdomain pro Sprache anlegt. Die englischsprachige Website ist dann unter en.example.com zu finden, die deutschsprachige unter de.example.com.

Die gängigste Lösung besteht aus einem Unterverzeichnis pro Sprache. Die englischen Seiten liegen also unter www.example.com/en/, die deutschen unter www.example.com/de/.

Denkbar ist auch eine Sprachkennung in Form eines Parameters im Query String. Die englische Homepage wäre dann über www.example.com/home?lang=en erreichbar, die deutsche über www.example.com/home?lang=de. Diese Variante ist allerdings für Benutzer weniger klar und auch aus SEO-Sicht nicht ideal.

Eine weitere Möglichkeit besteht darin, mit Top-Level-Domains zu arbeiten. Die englische Website wäre in diesem Fall www.example.com, die deutsche Website www.example.de. Dieser Ansatz ist aber insofern problematisch, als Top-Level-Domains nicht für Sprachen, sondern für Länder stehen. Die englische Website könnte genausogut unter www.example.us, www.example.co.uk, www.example.ca oder www.example.com.au zu finden sein. Bei www.example.ch wäre dafür unklar, ob man hier deutsche, französische, italienische oder romanische Inhalte findet.

Was sind hreflang-Links? Warum sind sie wichtig?

Ein hreflang-Link verknüpft unterschiedliche Sprachversionen derselben Seite. Auf einer dreisprachigen Website würde beispielsweise die deutsche Seite «Über uns» im <head> den folgenden Code enthalten:

<link rel="alternate" href="https://www.example.com/de/ueber-uns/" hreflang="de">
<link rel="alternate" href="https://www.example.com/en/about-us/" hreflang="en">
<link rel="alternate" href="https://www.example.com/fr/a-propos-de-nous/" hreflang="fr">

Die Verlinkung der Sprachversionen ist aus zwei Gründen wichtig. Erstens wird es so einfacher, dem Website-Besucher jene Seitenversion anzuzeigen, die seiner Sprachpräferenz entspricht. Zweitens signalisiert man einer Suchmaschine, welche anderen Seiten denselben Inhalt, aber in einer anderen Sprache enthalten und beugt so Problemen mit Duplicate Content vor.

hreflang-Links muss man nicht manuell pflegen, sondern sie werden automatisch durch das Mehrsprachigkeits-Plug-in generiert.