That is because wp-admin language settings are saved for logged-in user, but the user data is not loaded until you log in.
However, if you have defined default language in wp-config.php, you should see your login screen in that language.
Another thing is that textdomains of themes and plugins have to be loaded after init action hook (which is even after after_setup_theme hook) to be in language detected by Polylang.
Thanks Andy, I had cleared that global WPLANG from wp-config.php because of qTranslate. It’s back in now… But it does not seem to change the language of the login screen.
Strange.
You’re right, I just tested myself and it appears that Polylang is loading its front-end class Polylang_Core instead of Polylang_Admin because is_admin() returns false before user has logged in.
Correct locale was loaded when I disabled Polylang by commenting out last two lines in polylang.php (which is the fastest way to do it without logging in).
I suppose there should be another way to check if the back-end is loaded before user logs in.
Edit: maybe Polylang can check $pagenow == 'wp-login.php' besindes is_admin() as it is WordPress global defined in wp-includes/vars.php and used in wp-settings.php.
Edit #2: I just checked and the switch works. If you really need it and are ready to modify code of Polylang, just make changes in polylang.php around line 81 to 86:
// separate admin and frontend
global $pagenow;
if (is_admin() || $pagenow == 'wp-login.php') {
require_once(PLL_INC.'/admin.php');
$polylang = new Polylang_Admin();
}
I’m actually having another problem because Polylang delays textdomain loading until wp action which is too late as I need my custom post type labels in init hook.
Plugin Author
Chouby
(@chouby)
I never payed attention to this, but you are right, Polylang always forces the wp-login.php to English. Thanks you for bug report 😉
I propose to solve this using the language of the last page visited on frontend (in fact the cookie I set). Technically I will call Polylang_Core::load_text_domains in the login_init action.
I am sorry but I will be less present on the support forum during spring and summer. My activity is greatly seasons dependant.
Plugin Author
Chouby
(@chouby)
I’m actually having another problem because Polylang delays textdomain loading until wp action which is too late as I need my custom post type labels in init hook
Sorry, I did not pay attention to this at first reading. It’s true that (on frontend only) Polylang delays text domain loading up to wp mainly because it needs the wp_query object beeing created to know which language to apply. On admin side, the text domain is loaded normally. Could you explain why it is a problem ?
@chouby
Could you explain why it is a problem ?
I create my custom post types in init action hook as suggested by the Codex examples of register_post_type, but textdomains are not loaded yet at that point. I could modify those labels later, but that duplicates code and doesn’t make much sense.
I can register them after wp hook, but then CPT rewrite rules would not be modified by Polylang as that is done in wp_loaded which comes before wp unless Polylang hooks onto registered_post_type.
Another option for Polylang to get $qury_var['lang'] would be to hook onto parse_request but at that point $wp_query is not yet populated and hence there is no $wp_query -> queried_object.
Plugin Author
Chouby
(@chouby)
I am sorry but I do not understand what is the problem. Why do you want to modify the labels ? If your labels are internationalized – I guess they are 😉 – they will be automatically translated when displayed.
Do you mean you are using these labels between the init and the wp action ?
Those labels are stored as strings returned from gettext functions __('Label', 'textdomain') and _x('Label', 'context', 'textdomain') when post types are registered with register_post_type().
See example in codex.
At that point textdomains are not loaded yet and that’s why labels are not translated.
Plugin Author
Chouby
(@chouby)
Understood now. They are *stored*. Up to now I thought that these labels were used only on admin side and so not affected by the fact that Polylang defers textdomain loading. But it seems that you want to use it on frontend too…
Coming back to the original topic, I uploaded a new dev version which should correct the wp-login.php language issue.
They are *stored*
Exactly. They are used in CPT archive titles by wp_title function and I use them in headings of theme.
Plugin Author
Chouby
(@chouby)
You are facing a strong limitation of Polylang. It is due to the fact that my first intention was to avoid using the language information in url as much as possible (interesting at least if for some reason, the plugin is deactivated for a while or if you install Polylang on a site which mixed posts in different languages on a monlingual installation).
Other plugins (WPML, qtranslate) are hooking in ‘plugins_loaded’ which is called before ‘init’ (even before the default text domain is loaded). Here they are just looking for the language code to detect the language. Pro: they don’t face the same issue as Polylang (in which I am obliged to defer text domain loading after all post types and taxonomies are registered). Con: they are obliged to add the language code to all urls.
So today I believe that there is no other choice than registering post types two times to get your labels in the correct language (I must add this information in the documentation !).
but that duplicates code and doesn’t make much sense
You may be surprised as I was discovering this, but WP is exactly doing this for all default post types and taxonomies. They are registered a first time very soon in the loading process, just before plugins are loaded, before the default text domain is loaded (an thus here labels are not translated) an a second time in a function hooked to the init action (here the labels ae translated)…
No, I’m not surprised. 🙂
CPT labels are not translated if they are registered on init hook because that comes before wp action in which Polylang loads all textdomains.
Try this to see all actions until wp:
$actions_run = array();
add_action('all', 'store_actions');
function store_actions(){
global $actions_run, $wp_filter;
$tag = func_get_arg(0);
// skip actions without callback and gettext calls
if(isset($wp_filter[$tag]) && !in_array( $tag, array('gettext_with_context','gettext') ) ){
$actions_run[] = $tag;
}
}
add_action('shutdown','dump_actions_debug');
function dump_actions_debug(){
global $actions_run, $wp_filter, $wp_actions, $merged_filters;
echo '<b>All actions: </b><br />';
var_dump($actions_run);
echo '<b>$wp_actions: </b><br />';
var_dump($wp_actions);
}
add_action('wp', 'debug_just_exit', 1000);
function debug_just_exit(){
exit();
}
If post types were registered with register_post_type after Polylang had modified rewrite rules on wp_loaded action, those rewrite rules would be overridden, besause wp_loaded comes before wp.
Plugin Author
Chouby
(@chouby)
Up to now, my reference was this: http://codex.wordpress.org/Plugin_API/Action_Reference. But your code is very interesting. I made a plugin of it! Thank you for sharing.
In fact that code is from my debug plugin named Debuggy, which is active, but does nothing until it sees a special GET param to dump actions.
The codex is a great reference, but it’s not perfect because it’s a wiki and wikies are written by community. Order of actions in reference is not correct. That is exactly why I created the debug plugin.
I have the same problem. I did try to register my post types twice to no avail (I tried a few actions such as after_setup_theme, wp, wp_loaded, etc.).
It works when registering again the post types inside the theme, in the render method of a widget.
Any ideas?
