polylang – plugin not translated

What is this plugin? Is it internationalized? Has it the mo files in French?

The plugin is Groupbuyingsite. it is a premium plugin
https://groupbuyingsite.com/

it is supposed to be internationalized. All strings are translated using calls to __(). I have both .po and .mo files, but I have the feeling that the locale does not switch from EN to FR.
load_plugin_textdomain is called but I don’t understand why it might not switch locale.
Where should I look to understand what’s actually preventing the plugin from switching locale?
thanks!

where ‘load_plugin_textdomain’ is called? It’s common mistake to load the text domain as soon as the plugin is loaded, making impossible to multilingual plugins (which may be loaded after) to filter the language before the call . Even wordpress seo or jetpack had this issue in the past ??
So the function should not be called before ‘plugins_loaded’ has been fired.

Thanks Chouby, I can I make sure that load_plugin_textdomain is called only after plugins_loaded has fired?
With something like this?

add_action( ‘plugins_loaded’, ‘plugin_localization’ );

and then call load_plugin_textdomain in plugin_localization()?

I tried to do so but didnt work….
thanks
Claudio

Yes something like that should work with Polylang. But it may not be as simple as this. Did you remove the original ‘load_plugin_text_domain’ ? I’s also important that the plugin does not store localized strings in an array just after calling the ‘load_plugin_text_domain’ otherwise you will have to move this too, hoping that it is not needed before ‘plugins_loaded’ is fired. In fact a best practice for plugins would be to do nothing before ‘plugins_loaded’…

Hi Chouby,
I’ve almost got it. Now I understand what’s happening.
In class-wp.php I have this function

function main($query_args = ”) {
$this->init();
$this->parse_request($query_args);
$this->send_headers();
$this->query_posts();
$this->handle_404();
$this->register_globals();
do_action_ref_array(‘wp’, array(&$this));
}

What happens is that the other plugin is called within “parse_request” (dont ask me why, probably some pages may receive query string params), while polylang is executed within “do_action_ref_array”.
I found that if I add to the Polylang_Core constructor this line

add_action( ‘parse_request’, array( &$this, ‘load_textdomains’ ), 1 );

the plugin translation works. On the other hand this breaks the login logic (login page is blank) and when the user is not authenticated the language is stuck to the one set in the cookie.
It seems that this line breaks the user authentication model…

Do you have an idea on how force polylang to be executed during parse_request cleanly?
thanks!
Claudio

To explain a bit how Polylang works. There are two possibilities:

If you chose to set the language from content, then Polylang differs text domain loading. The text domain is no more loaded by WP, theme or plugins but by Polylang in a ‘wp’ action. I can’t do this sooner because I need to know what which content is loaded. In ‘parse_request’ we don’t know the content yet.

If you chose to set the language from the language code in urls, then the language is set in ‘plugins_loaded’ with priority 1. And the text domain is loaded normally by WP, theme and plugins. Polylang does not interfer.

The advantage of the first solution is that posts and pages urls are not modified. Thus if for some reason Polylang must be de-activated, no 404 error will be generated (except for archives as here we can’t avoid the language code in urls if we want to separate content from different languages).

However plugins are not aware that the text domain loading can be differed until ‘wp’ is fired. Thus even if nothing will be displayed before ‘wp’ action, they can just store some strings in variables before ‘wp’ is fired and use these variables later for display. In that case the first option is broken. Thus the second option is better for (some) plugins compatibility.

In any cases, if the plugin loads the text domain before ‘plugins_loaded’, Polylang currently can do nothing if the plugin is loaded before Polylang…

So I suggest that you choose to have the language code in all urls if this is not the case yet.

Thanks Chouby for the detailed explanation, it looked promising at first sight, but when I actually tried, it broke all the site and no page was reachable any more. The other plugin I’m using has some default pages (e.g. shopping cart) that do not follow the logic of having the language code in the url.
The thing is that when I add this line

add_action( ‘parse_request’, array( &$this, ‘load_textdomains’ ), 1 );

IT WORKS, but something goes wrong with the authentication mechanism and the switch from one language to another.
I mean that the parts of the site that are not translated with the standard config, are actually translated if I add this line.
I think I’m not too far, but don’t why loading text domains when “parse_request” is called breaks something.

It may seem to work but it can’t.

To know the language, we need either to know the content (not available before ‘wp’) or rely on a language code in the url. I don’t believe there are other possibilities.

If Polylang does not find a language from content, it will rely on cookie. Applying ‘load_textdomain’ to ‘parse_request’, Polylang will never find the language from content, thus you can’t switch the language.

Maybe your plugin is storing strings in variables between ‘parse_request’ and ‘wp’ (which would be rather curious, as if it does store strings, I would expect it to do before in ‘init’ for example).

When setting the language from content, Polylang stores all strings that WordPress attempted to translate in a private array Polylang_Core::labels. Maybe you can examine this array (in the function ‘load_textdomains’ attached to ‘wp’ action) to see if you find your plugin strings.

Thanks Chouby for the detailed answer. I was finally able to obtain the desired result and this might be of interest for you. Actually I modified polylang to use the “pll_language” to store the current language and update it at each language selector click.
I modified the function “the_languages” in core.php by modifying line 1024 as follow

$output .= sprintf('<li class="%s"><a href="%s">%s</a>'."\n",
						implode(' ', $classes),
						esc_attr($slug),
						esc_url($url),
						$show_flags && $show_names ? $flag.'?'.$name : $flag.$name
					);

[Moderator Note: Please post code & markup between backticks or use the code button. Your posted code may now have been permanently damaged by the forum’s parser.]

and then I added the JS for “updateCookie”. In this was any plugin can check the locale at any time and load the textdomain as needed. In my case it’s working pretty well.
thanks again for the support.