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. Der traditionelle Ansatz besteht darin, dass jede Seite ein Sprachkennung erhält und beim Übersetzen jeweils eine neue Seite in der Zielsprache angelegt wird. Ein anderer Ansatz besteht darin, unmittelbar beim Aufruf einer Seite die Originaltexte durch ihre Übersetzungen zu ersetzen (ähnlich wie man das von der Übersetzungsfunktion eines Browsers kennt); in diesem Fall existieren die Seiten weiterhin nur in ihrer Originalsprache. Es gibt auch den Ansatz, den Multisite-Modus von WordPress zu nutzen und pro Sprache eine weitgehend eigenständige Website anzulegen.

Jeder dieser Ansätze hat seine spezifischen Vor- und Nachteile bei der Erstellung und der späteren Pflege der Website. 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 traditionellen Ansatz, bei dem jede Seite in jeder Sprache existiert. 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 dem traditionellen Ansatz folgt. 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: Bei Polylang steht 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. Vor allem aber legt GTranslate für Übersetzungen keine neuen Seiten an: Die Übersetzungen werden nicht einmal in der WordPress-Datenbank gespeichert, sondern auf dem GTranslate-Server (einem sogenannten Translation Proxy). GTranslate ist auch 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.

Bei TranslatePress existieren Übersetzungen ebenfalls nicht als eigenständige Seiten – aber sie werden trotzdem lokal, d.h. in der WordPress-Datenbank auf dem eigenen Server gespeichert. Als Besonderheit arbeiten die Übersetzer hier 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 schliesslich noch 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. Multisite-Installationen sind ein interessantes Konzept, haben aber auch ihre Herausforderungen – MultilingualPress ist deshalb eher für grössere Websites geeignet, bei der die einzelnen Sprach- bzw. Länderversionen eine gewisse Autonomie brauchen.

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.