Customizer Optionen mit Polylang übersetzen

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,

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugins, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

2 Kommentare » Schreibe einen Kommentar

  1. Alternative:

    Dynamisch zusätzliche Customizer-Settings/Controls (z.B. header_en_US) anhand der definierten Sprachen erzeugen und dann je nach aktueller Sprache das entsprechende Setting ausgeben.

    Erspart zumindest den Weg über das Backend.

    • Das ist natürlich auch eine Variante. Der Vorteil wäre hierbei, dass bei einer Änderung des Originaltextes nicht alle Übersetzungen verloren gehen.

      Aber den Weg ins Backend erspart man sich ja nicht, da man hier die neue Customizer-Option befüllen muss. Bei mehr als zwei Sprachen wird das dann auch schnell recht unübersichtlich. Insgesamt ist es also wohl sehr viel mehr Programmieraufwand und nicht so flexibel.

Schreibe einen Kommentar

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