How does Polylang know which strings to translate?

If you’ve ever worked with Polylang you might’ve come across an instance in which you weren’t able to translate a certain plugin/theme string simply because it wasn’t registered in Polylang by the plugin/theme author.

This is frustrating because now we aren’t 100% able to translate our website. What if I tell you there’s actually a way to make Polylang work in these instances.

Normally what happens when using i10n (internationalization) to translate a plugin/theme an author wraps strings within a function. This could be either

__()

or

_e()

, well, there’s a few of them. Check out the wordpress codexPolylang has their own function to render strings,

pll__()

or

pll__e()

. Read more about these function here.Before Polylang is able to output these strings, they should first be registered by using

pll_register_string()

. So how do we translate strings that are outputting via the first set of functions that I talked about. Well let me show you.

The minimum requirements

Before any of this can work we have to make sure that the plugin/theme author has followed the proper i10n rules. Just to be certain, open the plugin files and make sure the string you are trying to translate is wrapping in any of these functions

In my example I’m going to use YITH WooCommerce Gift Cards. This plugin has been made ready for i10n, but isn’t compatible with Polylang.

As shown in this example, some of the strings have been automatically translated when activating Polylang, but other strings are persistent and do not get automatically translated.

So, how do we translate these strings?

To make actually work we are going to inject the Polylang translation function with the

gettext

hook.

function polylang_translate_incompatible_strings(
    $translated,
    $untranslated,
    $domain
) {
    if ($domain === "yith-woocommerce-gift-cards") {
        return pll__($translated);
    }
    return $translated;
}

add_filter("gettext", "polylang_translate_incompatible_strings", 999, 3);

Let’s talk about what is happening here. You’ll notice that we are hook into

gettext

, which gives us 3 variables:

$translated, $untranslated, $domain

, these speak for themselves. We’re then doing a check to see if the current text domain is equal to the text domain of our incompatible plugin/theme. In our case

yith-woocommerce-gift-cards

. If it is equal, we then wrap our

$translated

string within the Polylang translate function

pll__()

. If it’s not equal to the text domain, we just return the translated string.

Before this function will work, we first need to register our strings within Polylang.

add_action("init", function () {
        pll_register_string(
            "yith-woocommerce-gift-cards",
            "Set an amount",
            "Yith Woocommerce Gift Cards"
        );
        pll_register_string(
            "yith-woocommerce-gift-cards",
            "Enter a message for the recipient",
            "Yith Woocommerce Gift Cards"
        );
        pll_register_string(
            "yith-woocommerce-gift-cards",
            "Add to cart",
            "Yith Woocommerce Gift Cards"
        );
}, 9999);

Hook into the

init

action hook and register all the incompatible strings. Note that I used a priority of

9999

. This is because in some cases taking a low priority doesn’t work, so just to be safe, take it up a notch.

When done correctly you should now be able to translate your strings.