Translate Customizer options with Polylang

When it comes to translations, my favorite plugin is MultilingualPress. For a new client project with a small budget and only a couple of static pages, we decided to choose Polylang, which doesn’t require a Multisite.

Issues translating content

One of the main reasons I prefere MultilingualPress over other solutions is the fact, that is uses the Multisite functionality of WordPress. In this case, it’s usually pretty easy to translate any aspect of the website. It’s even possible to use different theme, plugins, widgets, menu item, etc. With a single site installation, some texts are only available ones, like plugin properties and also Customizer options.

In the mentioned project, the theme provided a Customizer option for contact information used on the front page next to the header logo, as well as a textarea for a custom footer. As on a German website you usually link to the „Impressum“ and the privacy policy, that was one of the options we needed to be able to translate. But also the contact information at the top had some texts that should be translated, such as dates.

Using a child theme for the translations

Unfortunately, I couldn’t find a way to solve the translation issues with the theme’s codebase. So I decided to implement a child theme, in which I’ve overwritten the header and footer templates. The header for example looked like this:

<div class="intro-wrap">
  <?php echo wp_kses_post( wpautop( get_theme_mod( 'header_intro' ) ) ); ?>
</div><!-- end .intro-wrap -->

The header_intro is a Customizer option that is taken from the option and just printed out. The can not change if with a filter. So how can we still translate it into the different languages? We simple have to wrap it with the pll__ function, the Polylang API is providing:

<div class="intro-wrap">
  <?php echo wp_kses_post( wpautop( pll__( get_theme_mod( 'header_intro' ) ) ) ); ?>
</div><!-- end .intro-wrap -->

Now the text would be translated, if such a translation exists for the current language. But how do you actually translate the option?

Register text for translations

To be able to translate any string, you have to tell Polylang about it. We use the function pll_register_string form the Polylang API to do that. In our functions.php file, we add these lines:

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;

First we check, if the functions exsists, as otherwise we might cause a fatal error, if we deactivate Polylang. Then we register a callback function and in this function we use the Polylang function to register the string. The first parameter is just a name to order the translatable string. The second parameter is the actual text we want to translate. In this case, we use the dynamic Customizer option value. The third parameter is to group strings and the last parameter tells the function, that it’s a multiline strings, so in the backend we see a textarea rather than a single line text input.

Doing the translation

All registered string can be translated using the settings page „Polylang -> Strings translations“ in the backend. Here we should find the current value of the string an a textarea per language we have configured in Polylang. It’s important to keep in mind, that every time the Customizer option is changed, we have to update the translation as well, as the original string has changed.

Conclusion

As you can see, translating Customizer options per language is also possible when using Polylang. But we need to create a child theme in most cases. Translating options of plugins can be a lot trickier, as we can not simple create a child plugin. We usually have to use the filters, a plugin might provide to change it’s texts and option. This is also the reason why I still prefer a Multisite approach when I need a multilingual website.

Bonus tip

As Polylang is a rather new plugin, much newer then WPML (which I usually don’t use), it support the WPML language configuration file wpml-config.xml, so if your theme says, that it’s WPML ready and has this file, you can probably skip some of the steps I’ve shown you in this blog post, or even all of them.

Veröffentlicht von

Bernhard is a full time web developer who likes to write WordPress plugins in his free time and is an active member of the WP Meetups in Berlin and Potsdam.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.