pll_e and pll__ echoing the NAME of my custom strings and not the CONTENT

  • I’m having a very bizarre issue, as it’s occurring (it seems) randomly. I place two pll_e or pll__ commands one after the other with two different translation strings I’ve correctly setup in my functions.php (and are both showing up in the Strings Translations section of my WP dashboard) and one works, but the other doesn’t. The one that’s not working just spits out whatever I’m placing between the quotations marks in my pll_e or pll__ command, i.e. if I write pll_e( 'stringname' );, it will echo stringname.

    The reason I’m placing them side by side is to test them out. Because the two instances that don’t work, seem not to work throughout the site!

    I’ve tried everything and can’t figure out why.

    All my custom strings are correctly registered in my functions.php using this format:

    pll_register_string( 'stringname', 'stringcontent' );

    I’ve checked and rechecked; and in fact all of them are appearing correctly in the Strings Translations sections, as I mentioned.

    It’s when I try to use them that only some of them work. And it doesn’t even have to do with the location of the pll_e or pll__ commands, as I’ve tried placing them all over the place to no avail…

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter xbonet

    (@xbonet)

    Just to update this issue, after extensive trials I’ve found that it’s not even that the functions are echoing the name of the string, they’re actually just echoing whatever one writes in them… so if I write pll_e('stringname') it echoes out “stringname” and if I write pll_e('flying-pink-cats') it echoes out “flying-pink-cats”… What’s going on, then?

    Plugin Author Chouby

    (@chouby)

    Hi,

    That’s because the correct parameter of pll__() is the string content, not the string name. Just as the native WordPress function __(). The string name is just used for your convenience for searching strings in the strings translations table.

    Thread Starter xbonet

    (@xbonet)

    Ok, I understand that specification; however, when my registered string is

    pll_register_string('Find out more', 'Find out more');

    and I try to echo it out using

    pll_e('Find out more')

    or

    echo pll__('Find out more')

    in all language instances, I get as a result “Find out more”… that is, it’s not echoing the translated strings I’ve specified in the Strings Translations section in WP.

    In all cases I’m using, both the stringname and the stringcontent are the same, so even though I was initially confused between which should be used with pll_e() and pll__(), in practice the issue is still the same: these are echoing whatever I place between the ('') and not actually the string content.

    @xbonet did you find out what’s wrong? I’m having EXACTLY the same issue.

    Hi, I am having the same problem with pll__() function, but pll_e() echoes the translated string.

    quick question to all who seem to have this issue, are you by any chance using pll__/pll_e in your admin page requests (eg in a plugin)?

    I am facing the same issue only when I use these functions in admin page requests. I suspect that the translations are not loaded for admin requests. I am going to dig a little deeper to find out if this is the case and report back here with my investigation.

    nailed it! Turns out the that the function pll__ and pll_e uses a built-in textdomain called ‘pll_strings’ to load the translations. To load the translated domain, polylang call the WP function get_locale() which in an admin request always returns the locale of the dashboard, in my case I have my WP installation setup to en_GB, and therefore I keep getting the ‘en’ locale string for all translations I load with the function pll__.

    So what’s the solution?

    Polylang provides another method to access your translation strings, pll_translate_string($string, $lang). In my case, I used the following code to get the translations,

    global $post; //this works when I am building a a request on a page/post that is translated by polylang.
$lang = pll_get_post_language($post->ID); //this returns the language of the post/page.
$translated_string = pll_translate_string('Know More', $lang);

    hope this works for you guys.

    I raised a BUG issue to notify the plugin developer of a more efficient way to fix this.

    yoavxyoav

    (@yoavxyoav)

    I got the exact same issue.
    pll_e(“LOGO”); actually prints the string “LOGO” and not its content.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘pll_e and pll__ echoing the NAME of my custom strings and not the CONTENT’ is closed to new replies.