Make strings translatable via Polylang

I use the “Polylang” tool on allsky-rodgau.de to offer the blog in German and English. In addition to the relatively simple creation of translations for blog posts, Polylang also enables the translation of individual text modules in plugins and themes that are not automatically covered by WordPress or theme language files. To do this, strings must be explicitly registered so that they appear in the backend under “String translation” and can be maintained for each language.

Why register strings?

Hard-coded or dynamically generated texts are not automatically transferred to PO/MO files by WordPress. Polylang therefore requires registration so that it can recognize these texts and make them translatable. This is particularly important for themes and plugins that contain many static UI elements.

Register strings with pll_register_string

The central mechanism is the pll_register_string function. It should be executed once when the theme or plugin is initialized.

function mytheme_register_strings() {
    pll_register_string(
        'header_tagline',
        'Your sky. Your data. Your view.',
        'Theme Header'
    );
}
add_action('init', 'mytheme_register_strings');

After registration, the string becomes visible in the Polylang backend and can be customized there for specific languages.

Output strings in the theme or plugin

pll__ is used to output a translated string. This function returns the appropriate language version.

echo pll__( 'Your sky. Your data. Your view.' );

Alternatively, pll_e can be used to output the text directly:

pll_e( 'Your sky. Your data. Your view.' );

Structuring and grouping strings

The third parameter of pll_register_string defines the string group. It is used to organize many text modules and facilitates work in the backend.

pll_register_string(
    'footer_disclaimer',
    'Allsky images are updated automatically every few minutes.',
    'Livepage'
);

pll_register_string(
    'button_label_more',
    'Learn more',
    'Buttons'
);

So the order is always:

function mytheme_register_strings() { 
    pll_register_string( 
        'welcome_message', 
        'Welcome to my Allsky project! 
        'Frontend Texts' 
    ); 
} add_action('init', 'mytheme_register_strings');

And then adjust the theme or plugin in the appropriate place to output this:

<div class="welcome-text"> 
    <h2> 
        <?php echo pll__( 'Welcome to my Allsky project!' ); ?> 
    </h2> 
</div>

A clear structure ensures better maintainability, especially for larger themes.

Also possible: Register dynamic strings

Texts from theme options or the Customizer can also be made translatable. A defined default value is required.

function mytheme_register_dynamic_strings() {
    $cta_text = get_option('mytheme_cta_text', 'Start exploring now');
    pll_register_string('cta_text', $cta_text, 'Theme Options');
}
add_action('init', 'mytheme_register_dynamic_strings');

This also allows user-defined frontend elements to be mapped in multiple languages.

Useful tips:

Name strings meaningfully, use unique keys
Segment groups clearly (header, footer, buttons, system texts)
Never perform registration within templates or loops
After changes in themes or plugins, check whether new strings need to be registered