Plugin Author
Chouby
(@chouby)
How are you doing ajax? Do you use the standard WordPress way?
I am expecting that Polylang detects an ajax request thanks to the DOING_AJAX constant defined in admin-ajax.php and then setups the language according to:
1. the ‘lang’ parameter if available in request
2. the language defined in cookie if available
3. the default language
Hello,
Thank you for your reply.
Yes I am using the standard WP AJAX method :
$.post(ajaxurl, {action: ‘get_products’, …});
The global ajaxurl var created by WordPress references /wp-admin/admin-ajax.php
A simple die/var_dump show that DOING_AJAX is set to true inside of set_language()
My default language is set to French.
Thanks again for your time.
Plugin Author
Chouby
(@chouby)
So there is probably something wrong.
Based on DOING_AJAX, I set another constant PLL_AJAX_ON_FRONT, in polylang.php, line 88
Based on this, the call to set_language() is made in choose-lang.php at line 29:
if (PLL_AJAX_ON_FRONT || false === stripos($_SERVER['SCRIPT_FILENAME'], 'index.php'))
$this->set_language(empty($_REQUEST['lang']) ? $this->get_preferred_language() : $this->model->get_language($_REQUEST['lang']));
And get_preferred_language() defined at line 70 in the same file, should always return a valid language.
Could you check if PLL_AJAX_ON_FRONT is correctly set and what is the value returned by get_preferred_language()?
Hi Chouby,
I’m experiencing a similar problem. I update a calendar via ajax, on admin side (wp_ajax_* hook, get_locale() is returning the default locale).
This can be ‘fixed’ by attaching ?lang=[code] to the ajax endpoint (ala admin_url('admin-ajax.php')), but I feel it should be Polylang that does this. E.g.:
function polylang_maybe_add_lang( $url, $path, $blog_id ){
if( $path == 'admin-ajax.php' ){
$url = add_query_arg( 'lang', 'fr_FR', $url );
}
return $url;
}
add_filter( 'admin_url', 'polylang_maybe_add_lang', 10, 3 );
(Trying this I broke some of my own plug-ins because I blindly, and foolishly, hard-code ?param=var, but that's my fault. Understandably you might not want to do something that might reasonably be expected to break plug-ins).
A more robust solution would be to use cookies, which your original post suggest is what the plug-in does do. Is this something that needs to be explicitly enabled?
(Ooops, I obviously hard-coded the locale in that snippet, but that was for testing purposes…)
Ah, I was working on a localhost and you set the domain argument in setcookie() to localhost, which is why the cookie wasn’t stored (see http://stackoverflow.com/questions/1134290/cookies-on-localhost-with-explicit-domain).
It might be an idea to set the domain to FALSE when on a localhost environment. However, I found, simply not specifying the domain argument worked.
Plugin Author
Chouby
(@chouby)
Hi Stephen!
Thanks for the tip. I was not aware of this possible issue. I develop on localhost but never ran into it (using FF and Chromium). I used to set the domain to false in the past until I implemented the possibility to use subdomains for which I needed to specify the domain.
So in the development version (1.5.4.3), I set the domain to COOKIE_DOMAIN (false by default) except when using the subdomains.
http://downloads.wordpress.org/plugin/polylang.zip
