Wenn es um das Übersetzen von WordPress Seiten geht, ist mein Lieblingsplugin MultilingualPress. Für ein neues Kundenprojekt mit sehr kleinem Budget, das nur wenige statische Seiten hatte und bei dem eine Multisite nicht umbedingt notwendig war, haben wir uns aber für Polylang entschieden.
Probleme bei der Übersetzung der Inhalte
Einer der Hauptgründe, weshalb ich MultilingualPress gegenüber den anderen Lösungen bevorzuge ist die Tatsache, dass es auf die Multisite-Funktionalität von WordPress aufsetzt. In diesem Fall ist es nämlich sehr einfach wirklich jeden Bereich der Website zu übersetzen. Selbst die Verwendungen unterschiedlicher Themes, Plugins, Widgets, Menüeinträgen, usw. ist hiermit ohne weiteres möglich. Mit einer normalen WordPress Installation sind manche Texte nur einmal vorhanden, wie etwa die Einstellungen eines Plugins und die Customizer Optionen.
In dem erwähnten Projekt hat das Theme Customizer Optionen angeboten, um auf der Startseite im Header Kontaktinformationen direkt neben dem Logo zu platziern. Weiterhin konnte man den Text im Footer über eine Textarea überschreiben. Das braucht man auf einer deutschen Website auch meisten, da hier in der Regel die Links zu Impressum und Datenschutzerklärung positioniert sind. Diese Optionen mussten also übersetze werden, ebenso wie die Kontaktinformationen im Header, da hier Uhrzeiten angegeben waren.
Erstellung eines Child Themes für die Übersetzungen
Leider konnte ich keine Lösung finden, die mit der Codebasis des Themes umgesetzt werden konnte. Also habe ich mich dazu entschlossen ein Child Theme zu erstellen, das das Header- und Footer-Template überschreibt. Der Header sah in etwa wie folgt aus:
<div class="intro-wrap">
<?php echo wp_kses_post( wpautop( get_theme_mod( 'header_intro' ) ) ); ?>
</div><!-- end .intro-wrap -->
Die Customizer Option header_intro wurde hierbei einfach nur ausgeben. Es gibt hier keinen Filter auf den Wert, den man verwenden konnte. Wie kann man den Text also dennoch übersetzen? Hierzu bietet die Polylang API die Funktion pll__, mit der der Wert vor der Ausgabe übersetzt werden kann:
<div class="intro-wrap">
<?php echo wp_kses_post( wpautop( pll__( get_theme_mod( 'header_intro' ) ) ) ); ?>
</div><!-- end .intro-wrap -->
Nun kann der Text übersetzt werden, wenn eine solche Übersetzung für die aktuelle Sprache exisiert. Aber wie genau funktioniert die eigentliche Übersetzung der Option?
Texte für die Übersetzung registrieren
Damit man einen Text überhaupt erst übersetzen kann, muss man Polylang mitteilen, dass es ihn gibt. Hierzu wird die Funktion pll_register_string der Polylang API verwendet. In die function.php Datei fügt man einfach folgene Zeilen ein:
if ( function_exists( 'pll_register_string' ) ) :
/**
* Register some string from the customizer to be translated with Polylang
*/
function child_theme_name_pll_register_string() {
pll_register_string( 'header_intro', get_theme_mod( 'header_intro' ), 'child-theme-name', true );
}
add_action( 'after_setup_theme', 'child_theme_name_pll_register_string' );
endif;
Zuerst wird überprüft, ob die Funktion existiert, da es ansonsten zu einem Fatal Error kommen würde, sobald Polylang deaktiviert wird. Anschließend wird eine Callback-Funktion registiert, in der die Funktion zur Registrierung von Texten verwendet wird. Der erste Parameter ist hierbei lediglich ein Name zur Sortieung der übersetzbaren Strings. Der zweite Parameter ist der eigentliche Text, der übersetzt werden soll. In diesem Fall ist es der dynamische Wert der Customizer Option. Der dritte Parameter definiert eine Gruppe für der String und der letzte besagt, dass es sich bei der Text um einen mehrzeiligen Text handelt. Somit wird bei der Übersetzung im Backend eine Textarea und kein einzeiliges Textfeld verwendet.
Den Text übersetzen
Alle reigistrierten Strings befinden sich unter „Sprachen -> Übersetzungen von Zeichenketten“ im Backend. Hier steht in einer Tabelle in der ersten Spalte der aktuelle Wert aus dem Customizer und in der letzten Spalte kann dieser Text dann pro Sprache übersetzt werden. Hierbei ist zu beachten, dass bei jeder Änderung des Wertes in der Customizer Option auch die Übersetztung neu vorgenommen werden muss, da ansonten der unübersetzte Wert in allen Sprachen verwendet wird.
Fazit
Es ust auch mit Polylang möglich, die verschiedenen Optionen des Customizers pro Sprache anzupassen. Hierzu muss aber in den meisten Fällen ein Child Theme erstellt werden. Die Übersetzung von Optionen eines Plugins können schon viel schwieriger werden, da man hier nicht einfach ein „Child Plugin“ erstellen kann. Dabei ist man dann meistens auf Filter angewiesen, die das Plugin dann hoffentlich anbietet, um Texte anzupassen. Das ist auch ein weiterer Grund, wieso ich bei mehrsprachigen Seiten eher zu einer Multisitelösung tendiere.
Bonustipp
Da Polylang ein noch eher neues Plugin ist, sehr viel neues als WPML (das ich in der Regel nicht nutze), unterstützt es das sogenannten WPML language configuration file wpml-config.xml, was einem ein bisschen Arbeit erspart. Wenn also das Theme sagt, dass es „WPML ready“ ist und eine solche Datei mitliefert, können eventuell einige der Schritte übersprungen werden, die ich in diesem Beitrag gezeigt habe,
