Support » Plugin: Polylang » pll_register_string only in Backend?!

  • Hello there,

    I’m trying to set up a custom theme and obviously I have a few strings such as “read more” that need to be translated.
    Now I found Choubys Code Snippet on Pastebin.

    Unfortunately, it doesn’t do what I want. I need to be able to register strings within my Theme, but pll_register_string is limited to backend use. Why would a Theme developer do that? I can’t be bothered to create some plugin in the backend just to create strings. Unfortunately one can’t manually create a new string in the Polylang backend.

    So, what’s the approach on that?

    Thanks in advance!

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Chouby


    Polylang does not modify how the themes/plugins developers should handle their strings. See here or the codex

    The goal of the couple of functions pll_register_string (on backend) / pll__ (on frontend) is to allow for the translation of user defined strings which are generally stored in options, as it is done for the Responsive theme options in the example you cite.


    Seems like I didn’t really grasp that concept. Can you explain where I can find these

    user defined strings which are generally stored in options



    Plugin Author Chouby


    It much depends on the plugin/theme. But for example, since you mentioned the code to adapt the Responsive theme, the options are found in Appearance->theme options->Home page (headline, subheadline, content area…)

    pll_register_string says “I want to translate these strings in the translations list table found in settings->languages->strings translation”

    Hi Chuoby,

    Thanks a lot for your time. After looking for a possibility to get that backend options page for my own custom theme, I noticed that implementing such a feature would require me to dig deep into WordPress and I don’t really have the time for that right now. Then I stumbled upon this thread of yours and it is really tempting to just implement those lines of code and make it work.
    Now what made me really curious is that this approach is based on using the _e() function. And Polylang offers a similar function, pll_e().
    Now why would I even need pll_e() when WordPress itself with its (limited?) i18n capabilities offers me to translate custom strings?! How does it even differ?

    Would really appreciate your help
    Thanks a lot!

    Plugin Author Chouby


    When you use _e('some_string', 'some_domain'), WordPress translates the string according to the right language (either defined in the wp-config.php file for a single language installation or defined by Polylang for a multilingual installation). The translation is found by WordPress in a .mo file. WordPress knows where to find this file thanks to load_plugin_texdomain or load_theme_textdomain.

    When you use pll_e('some_string'), Polylang does the same but looks for the translation in the database.

    The first function uses a static approach. The strings are created in English in the .php file by the theme (or plugin) programmer and translated in the po/mo files by the theme (or plugin) translator.

    The second function uses a dynamic approach. The strings and the translations are created by the user and stored in the database.

    Hi again,

    Thanks a lot for the explaination! For the static text in my template I don’t really need easily changable translations, so I just used the WordPress functionality with __(), which works great.

    Now I have a different question, my client might want every (currently available in english) content entry duplicated for each language. So that when you view the german version of the blog, all entries are shown, no matter if there is already a real translation available or not.
    Is this possible dynamically or do I have to manually copy each post?

    Plugin Author Chouby


    If I well understood, this should answer your question.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘pll_register_string only in Backend?!’ is closed to new replies.