• My question is similar to this one here: https://www.ads-software.com/support/topic/pll_language-cookie-setting-wrong-language/

    When I call get_locale(), I always get the root language of the page, even if the page is shown in a different language. When observing the cookies, I can even see on page load that the cookie of for example the french page (which is not the root) is correctly set to ‘fr’; as well as the lang attribute of the pages’ HTML tag is correctly set to fr-FR. Weird thing is that the value of the pll_language cookie automatically switches to ‘de’ (which is the root language) upon page load, while the value of the lang tag stays correct. Any idea why that’s the case?

    The automatical switch of the ‘pll_language’ cookie value happens with some delay after pageload, so this seems to be due to some javascript of your plugin. When I for example do echo get_locale() in the page template within the body tag, the correct locale (‘fr-FR’) gets echoed out, the page finishes loading, and then the pll_language cookies value switches to ‘de’. What’s causing this; it’s super annoying and obviously breaks the entire locale-based navigation..

    As additional hint; this happens when I do get_the_permalink(pll_get_post(13,substr(get_locale(),0,2)))
    on the backend, forward the result to the frontend, and redirect to that page in js via window.location = that value. Note that 13 here is the ID of the concerned page in whatever language. The redirect happens without any errors (page is loaded with html lang attribute value fr-FR, in french, and french localizations of my custom plugins are correctly retrieved. But then the pll_language cookie is reset to de and subsequent REST API calls etc. erroneously use the ‘de’ locale, if get_locale is called within them, and that’s obviously a huge problem). It also happens when I add links to my pages via get_the_permalink(pll_get_post(13,substr(get_locale(),0,2))). In this case, the tooltip shows the corresponding link in the correct language, the according page is accessed without any issues when clicking on it, but the pll_language cookie reset to the default language still persists.

    What is causing this?????

    It seems to happen more frequently on pages where the language switcher is not present, after the first REST API request is executed via js, and the page is then reloaded. If that may help.

    • This topic was modified 1 year, 8 months ago by joeyojoeyo12.
    • This topic was modified 1 year, 8 months ago by joeyojoeyo12.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter joeyojoeyo12

    (@joeyojoeyo12)

    Another note: When calling get_locale() when a REST API request is incoming and the pll_language cookie is still correct, I get the wrong language code ‘de’ instead of ‘fr’; and when using pll_current_language() at the same moment; I get bool false; if that may help

    • This reply was modified 1 year, 8 months ago by joeyojoeyo12.
    Thread Starter joeyojoeyo12

    (@joeyojoeyo12)

    Another problem is that WP REST API Responses which are localized with WPs’ built-in __() localization functions are retrieved in the wrong message; and I suppose that’s due to this locale problem. Can someone please tell me how to fix this; otherwise Polylang does not appear to be a reliable localization plugin for us..?

    So maybe the actual question answering to all the issues of this topic is: How can I safely retrieve the locale in WP REST API callback, registered via register_rest_route, using polylang, and thus also make sure that strings sent in the response which hold localizations via __() are sent in the accordingly correct language back to the client?

    • This reply was modified 1 year, 8 months ago by joeyojoeyo12.
    • This reply was modified 1 year, 8 months ago by joeyojoeyo12.
    • This reply was modified 1 year, 8 months ago by joeyojoeyo12.
    • This reply was modified 1 year, 8 months ago by joeyojoeyo12.
Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘get_locale() returning root language instead of current locale’ is closed to new replies.