joeyojoeyo12

After a little bit of research, it seems to us that we have two options:

A) With every REST API request, we deliver a custom Accept-Language: <our-locale-string> header, with the value of <our-locale-string> being something like de (retrieved from the lang attribute of our html tags, generated correctly via polylang). At the beginning of the callback processing the request, we then use switch_to_locale to switch the locale to the one the client is supposed to accept, send the __() strings to the client, which are thus supposed to arrive in the correct language, and after that, restore the locale via restore_previous_locale . Do you see any risk with this approach?

B) We import our localizations from our PO files which our __() are currently using into polylang, via pll_register_string . In this sense, it would be important to do this programmatically, as we have tons of localizations, and are using the free version of polylang. As we understood, pll_register_string is the function used to register a new string used as key; but which pll_ function can be used to add actual localizations of that string; is that not possible without Pro Version Imports ?? Then, we would need to replace all of our __() , esc_html__() etc calls with pll__ and the ones of them that are within REST API callbacks with pll_translate_string() by passing the additional <our-locale-string> explained above, provided via the Accept-Language: <our-locale-string> field. Here our concern is: How is the performance of the retrieval of pll__ and pll_translate_string() considering that we have around 1000 translations per language, and 6 languages? In the code, it seems that pll_register_string simply stores the values in an array, so we’re worried about the retrievals’ performance? Another thing we’re concerned of is security; as the pll__ , pll_e and pll_translate_string methods do not escape retrieved strings for safe HTML output, such as esc_html__ , correct?

Can you may help us among selecting among option A) or B), or an even better approach?

• This reply was modified 1 year, 11 months ago by 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, 11 months ago by joeyojoeyo12.
• This reply was modified 1 year, 11 months ago by joeyojoeyo12.
• This reply was modified 1 year, 11 months ago by joeyojoeyo12.
• This reply was modified 1 year, 11 months ago by 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, 11 months ago by joeyojoeyo12.

I have no other plugins installed, not even themes (I’m a professional senior developer:)).

To be more precise about the issue, the admin locale corresponds to the locale of the user when the admin page is loaded. So let’s say you have an admin user whose language is german; the admin page loads in german, with everything displayed in german.
If you check for get_locale() and get_user_locale(), they’re both german.

Now you then open the frontend on a different tab in the same browser, and then switch the language of the website to English.

Go back to the admin tab and reload the page. It is still shown in german, BUT, dynamic server feedbacks that use wordpresses’ usual localization functions like esc_html__() are now displayed in English.

Also, when I now check for get_locale() and for get_user_locale() in my admin, they both show English, although the menu labels etc. of the admin is shown in german.

This behaviour MUST be tied to your plugin, as I use no other plugins / themes in my wp environment. Any idea what’s going on?

Hi there,

Thanks a lot for your quick answer. In other words, I could basically automate the generation of multilingually associated wordpress posts, simply by:

1) Create six posts via wp_insert_post(), in their respective language;

2) Assign language to each post with pll_set_post_language($post_id, $lang);

3) Save the six posts as translations of each other with pll_save_post_translations( $arr );

Is that all, or did I forget something? I especially want to avoid to need to modify manually all the posts created in this automatic way, once a polylang update comes out. Please let me know, and thanks a lot for your help; much appreciated!

Best regards,

• This reply was modified 4 years, 11 months ago by joeyojoeyo12.