WordPress gibt es in vielen Sprachen, unter anderem natürlich auch Deutsch. Programmiert ist jedoch alles in englischer Sprache. Texte auf die Besucher im Frontend stoßen, sind jeweils in eine Funktion gefasst (gettext). Idealerweise werden sämtliche Texte ausgelesen und in einer Übersetzungsvorlage gespeichert. Mit geeigneten Programmen (eines der bekanntesten ist poedit) können sie dann in beliebige andere Sprachen übersetzt werden. Diese Programme sind auch in der Lage, die Codedateien direkt auszulesen, nur müssen die dann auch vorliegen. Daher sind Übersetzungsvorlagen – .pot-Dateien – zu bevorzugen, da sie unkompliziert an Übersetzer gesendet und dort direkt ausgelesen werden können, um dann die Sprachdateien in jeder gewünschten Sprache zu erhalten.

Keine Datei für Deutsch (Sie) – was bleibt ist Englisch

Wie fast jeder deutschsprachige Website-Betreiber, der schonmal WordPress installierte weiß, gibt es WordPress auch in seiner Sprache. Genauer gesagt, sogar in mehreren Varianten. Die mit Übersetzungen zu befüllenden Dateien mit formaler Ansprache enden mit de_DE_formal.po. Dann gibt es noch Deutsch für Österreicher, de_AT.po, Schweiz Sie, de_CH.po, Schweiz Du – de_CH_informal und die am meisten verbreitete de_DE.po in der „Du“-Form. WordPress startete seine Karriere als Blogsystem, und Blogs sind traditionell nicht förmlich.

Was direkt von WordPress-Entwicklern kommt, wie z.B. Themes aus der Twenty-Reihe oder WooCommerce, dessen Übersetzungen sind umfassend und gut gepflegt. Wer jenseits der Community einkauft wird übersetzungstechnisch machmal leer ausgehen (oder bekommt maschinelle Übersetzungen, die nicht immer ganz – schlüssig sind).

Es gibt fünf Varianten von Deutschsprachigkeit. Technisch gesehen sind es allerdings auch fünf verschiedene Sprachen. Welche Variante geladen wird hängt von der Spracheinstellung in WordPress ab. Bei Deutsch (Sie) wird nach Dateien gesucht, die mit de_DE_formal.mo (das ist die von Maschinen verwendete Version der Übersetzungsdatei) enden. Gibt es eine solche nicht für eine bestimmte Komponente, sieht man die originalen, unübersetzten Texte in Englischer Sprache. Das betrifft üblicherweise nicht WordPress selbst, sondern (nicht originale) Themes und Plugins. Vor allem bei Themes, mit denen praktisch das gesamte Frontend aufgebaut wird, fällt das Fehlen einer passenden Übersetzungsdatei somit gleich auf. Da hilft es tatsächlich wenig, dass WordPress selbst durch und durch in formales Deutsch übersetzt ist.

Manche Übersetzung kann auch mal in den Einstellungen überschrieben werden

Erwähnt, aber hier vernachlässigt sei, dass manche Texte (z.B. read more) in den Theme-Einstellungen – Customizer vorzugsweise – eingedeutscht werden können. Wer FSE-Themes verwendet, kann die Texte einfach in den Templates überschreiben, und schon hat er ein lokalisiertes Frontend (doch das ist wieder eine andere Geschichte…).

Das Theme und – soweit übersetzungsfähig – jedes Plugin hat seine eigene, individuelle sogenannte Textdomain. Anhand derer werden die einer Komponente zugehörigen zu übersetzenden Texte ermittelt und in einer Übersetzungsvorlage gruppiert. Vergisst ein Entwickler bei einem zu übersetzenden Text die Angabe der Textdomain oder vertippt sich, wird er gar nicht erst eingelesen, und bleibt in der Originalsprache. Übersetzungsdateien sind nicht immer Bestandteil eines Plugins, doch wenn, stehen die Chancen dafür, dass es eine de_DE.po (und de_DE.mo – das ist diejenige, die auf der Website verwendet wird) gibt, am größten. Formales Deutsch findet man nur in ein paar großen, weit verbreiteten Plugins wie WooCommerce, oder auch etablierten Premium-Plugins vor. Die Chance auf eine vollständig übersetzte Website schwindet, wenn man sich für eine „exotischere“ Deutsch-Variante entscheidet, für die es nicht so viele Anwender gibt.

Ein Deutsch und ein anderes Deutsch, das geht sehr wohl

Wie fein wäre es, wenn im Fall einer fehlenden de_DE_formal dann wenigstens die de_DE-Datei geladen würde… Tatsächlich geht das sogar, mit dem Plugin Language Fallback. So mischen sich zwar mithin „Sie“- und „Du“-Form, doch wenigstens werden alle verfügbaren deutschen Übersetzungen einbezogen. Verständlicherweise gibt es allerdings Unternehmen, die Ihre Besucher durchgehend formal anreden wollen. Die müssen dann ihre eigenen Sprachdateien anlegen und pflegen.

Was, wenn es überhaupt keine deutsche Übersetzungsdatei gibt?

Es gibt keine Garantie, dass jedes Plugin(oder jedes Theme) das man installiert überhaupt mit Übersetzungsdateien ausgestattet ist (oder in der Sprache / Variante, die man braucht). Fast immer kann man davon ausgehen, dass Komponenten „translation ready“ sind. Das bedeutet aber nur, dass gettext-Strings verwendet werden und eine Textdomain, nicht aber, dass die Übersetzung(en) bereits dabei sind. Manchmal muss man sich darum selber kümmern. Glücklicherweise gibt es dafür ein hilfreiches Plugin namens Loco Translate.

Loco Translate ist installiert, wie geht es weiter?

Zuallererst im Dashboard von WordPress unter Einstellungen nachsehen, welche Sprache installiert ist. Ist sie zum Beispiel Englisch und gewünscht wird Deutsch, diese Sprache aus der Liste wählen, und die Einstellungen sichern. Die verfügbaren Sprachdateien werden anschließend installiert. Eigene Sprachdateien für WordPress werden üblicherweise nicht benötigt, es sei denn, es ist gewünscht, verwendete Formulierungen umzuschreiben. Eigene Sprachdateien werden ansonsten nur für Komponenten benötigt, die keine Sprachdateien mitführen, oder keine in der eingestellten Sprache, was einem bei Deutsch (Sie) leichter passieren kann, als bei „Standard“-Deutsch.

Wer einen API-Key z.B. für Google- oder Loco-Translate hat, findet unter Loco Translate, Einstellungen im Tab API-Schlüssel Eingabefelder dafür vor und kann später neu angelegte Sprachdateien automatisch übersetzen lassen (Formulierungen anschließend prüfen!). In den Website-Optionen kann darüber befunden werden wie Loco vorgehen soll, wenn eine Komponente keine Template-Datei (.pot) enthält. Es wäre zwar möglich, eine Vorlagendatei durch Loco-Translate anlegen zu lassen, es können allerdings die Dateien einer Komponente auch direkt ausgelesen werden. Daher finde ich es sinnvoll, direkt mit der Quelle zu synchronisieren wenn keine Template-Datei vorhanden ist, zuzulassen (mit oder ohne Warnung).

Nach der Installation von Loco Translate gibt es drei Positionen im Untermenü, die zu Sprachdateien führen: Themes, Plugins und WordPress.

In den meisten Fällen dürfte eine (Teil-)Übersetzung des Themes erforderlich sein. Plugins die Inhalte die auf der Website sichbar sind ausgeben, und bei denen sich Begriffe nicht über eine Einstellung ändern lassen, sind ggf. auch Kandidaten.

Eine Übersetzungsdatei neu anlegen

Gibt es keine Übersetzungsdatei in der gewünschten Sprache, dann über den entsprechenden Link

„Neue Sprache“ hinzufügen. Sprachen die bereits installiert sind (eine Sprache wird installiert, indem man die WordPress-Spracheinstellung ändert, man kann sie nach der Installation der Sprache wieder zurücksetzen), stehen ganz oben zur Auswahl.

Darauf achten, dass als Ort „Individuell“ ausgewählt wird. Übersetzungen die hier liegen, bleiben auch nach Update erhalten. Allerdings sollten sie dann regelmäßig synchronisiert werden, da sich bie Update Formulierungen ändern oder neue hinzukommen können, für die dann die Übersetzung nachgezogen werden muss.

Wer mit eigenen Übersetzungsdateien arbeiten sollte diese also mehr oder regelmäßig pflegen. Wenn sich in einem Originaltext auch nur ein Zeichen ändert, wird die zugehörige Übersetzung bereits nicht mehr erkannt.

Eine Übersetzungsdatei klonen und (teilweise) ändern

Wie bereits erwähnt, stehen die Chancen auf das Vorhandensein einer deutschen Übersetzung deutlich besser, als die Chancen auf eine formale „Sie“-Version. In diesem Fall kann die bestehende Übersetzung als Vorlage verwendet, und als formale Version adaptiert werden (natürlich aber auch ebenfalls als de_DE.po – Datei, um Formulierungen die man sich anders wünscht umzuschreiben).

Mit „Kopieren oder als Vorlage verwenden“ lässt sich die Übersetzung in eine beliebige andere Sprache kopieren, wo sie dann z.B. als de_DE_formal.po nur an den erforderlichen Stellen in eine Sie-Version umgeschrieben wird.

Mit dem oben erwähnten Plugin „Language Fallback“ ist es allerdings auch möglich, eine neue formale Datei nur teilweise zu befüllen. Was dort fehlt, wird dann auch der Fallback-Deutschversion bezogen.

Ich sehe gar keine Tücken…?

Nun, manchmal kommt es vor, dass man einen String übersetzt, und trotzdem sieht man im Frontend nach wie vor einen Text in englischer Sprache. Das kann bedeuten, dass er nicht nur einmal vorkommt, sondern in einer anderen Komponente nochmal, jener nämlich, die den Text wiedergibt (beispielsweise indem das Template eines Parent-Themes oder eines Plugins überschrieben, und dafür eine eigene Textdomain verwendet wird). Das wiederum bedeutet, man muss suchen und rausfinden, welche Komponente es eigentlich oder zusätzlich zu übersetzen gilt.

Es kann aber auch bedeuten, dass eine Synchronisierung fällig ist, da sich ein String geändert hat (wenn auch nur geringfügig) und nochmal übersetzt werden muss. – Und natürlich kann es auch mal vorkommen, dass die Quelle eines Textes in den Einstellungen (vorzugsweise Customizer) zu finden ist. Bei Full Site Editing hingegen ändert man Texte wie „Continue reading“, „by“, „from“ etc. direkt in den Vorlagen (zumeist mehreren).

Wer Strings von Maschinen übersetzen lässt, wird sich vielleicht auch wundern, warum zwar alle Strings übersetzt sind, aber der Übersetzungsfortschritt dennoch bei 0% blieb, und nicht eine Übersetzung angewendet wird. In diesem Fall sehen die Strings vermutlich so aus:

Hier wurde darüber befunden, dass die Übersetzungen nur als Vorschläge zu behandeln sind und als noch zu überprüfen markiert blieben.

Werden die Übersetzungen von Maschinen einfach durchgewinkt, können sich später hingegen kontextfremde Begriffe im Frontend zeigen. Aus dem Monat Mai (May) wird dann „Dürfen“ oder ähnliches.