WordPress.org

Forums

Polylang
[resolved] wp-login.php always in english? (26 posts)

  1. RavanH
    Member
    Posted 3 years ago #

    Salut !

    After installing Polylang on two different sites, both with a different default language than English, I notice the wp-login.php redirect is in English. It does not seem to matter what browser language is set or which front-end language has been chosen before loggin in. Either by following the login meta link or going straight to /wp-admin/, the result is always an English login form...

    After login, the back-end is in the correct (default) language again.

    Rolf

    http://wordpress.org/extend/plugins/polylang/

  2. AndyDeGroo
    Member
    Posted 3 years ago #

    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.

  3. RavanH
    Member
    Posted 3 years ago #

    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.

  4. AndyDeGroo
    Member
    Posted 3 years ago #

    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.

  5. Chouby
    Member
    Plugin Author

    Posted 3 years ago #

    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.

  6. Chouby
    Member
    Plugin Author

    Posted 3 years ago #

    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 ?

  7. AndyDeGroo
    Member
    Posted 3 years ago #

    @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.

  8. Chouby
    Member
    Plugin Author

    Posted 3 years ago #

    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 ?

  9. AndyDeGroo
    Member
    Posted 3 years ago #

    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.

  10. Chouby
    Member
    Plugin Author

    Posted 3 years ago #

    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.

  11. AndyDeGroo
    Member
    Posted 3 years ago #

    They are *stored*

    Exactly. They are used in CPT archive titles by wp_title function and I use them in headings of theme.

  12. Chouby
    Member
    Plugin Author

    Posted 3 years ago #

    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)...

  13. AndyDeGroo
    Member
    Posted 3 years ago #

    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.

  14. Chouby
    Member
    Plugin Author

    Posted 3 years ago #

    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.

  15. AndyDeGroo
    Member
    Posted 3 years ago #

    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.

  16. puleddu
    Member
    Posted 2 years ago #

    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?

  17. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    Did you try 'wp' with priority > 10 ?
    Do you call 'load_plugin_textdomain' in a function hooked to 'init' ?

    Otherwise, you can try the development version of Polylang v0.9. It is no longer necessary to register post types and taxonomies two times *if you choose to add the language code in all urls*. See http://wordpress.org/support/topic/development-of-polylang-v09

  18. puleddu
    Member
    Posted 2 years ago #

    Using the priority argument worked. :)
    Thank you, Chouby!

  19. puleddu
    Member
    Posted 2 years ago #

    Hi all,

    in version 0.8.x using the language code in all url is marked as not recommended.

    What is the reason for this? And in 0.9 this warning has been removed. Things are changed and the two methods are now both equally supported and recommended?

  20. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    I added this possibility per user request in 0.7. I did not recommend it because I did not see any advantage in it (except for users migrating from another plugin) and there is one drawback: if for some reason, Polylang is deactivated, all external links are broken (it was one of my initial goal to avoid this). Of course, we are still obliged to keep the language code in url for archives. Moreover, as a new feature, it would have probably come with more bugs...

    All this was several months ago. I got more experience and saw some advantages in this possibility. The most important is that it is not mandatory to defer language files loading as for the other option. So starting from v0.9, if you use this option, the language files are normally loaded. Thus, I ewpect it will increase the compatibility with some plugins or themes.

  21. puleddu
    Member
    Posted 2 years ago #

    Thank you for you clarification.
    Now I can choose with confidence.

    Antonio

  22. TheDarkD
    Member
    Posted 2 years ago #

    I have the same problem. But didn't find any solution for it.
    Even now the plugin is deleted wp-admin keeps redirecting to /en/wp-login.php

    My first language of the website is not english. In wp-config the default language is not english.

    Any simple solution?

  23. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    Did you test other multilingual plugins?
    /en/wp-login.php is not a valid url for Polylang. And of course, once it is deleted (properly using the 'delete' link in the plugins page) all is reset as if Polylang was never installed.

  24. squalyl
    Member
    Posted 2 years ago #

    I still have the problem with Polylang version 0.9.4.

    I would call this problem "severe", since my site is trilingual (french, english, korean) and users of korean language will run away with a french login / registration form.

    Do you have a solution?

    Here is the default website home: http://www.inspiredmelodies.com/
    Here is the korean page: http://www.inspiredmelodies.com/ko/
    Here is a protected page: http://www.inspiredmelodies.com/download-kr/#.UKFynmcnGnB
    On this page the link "가입하기" is a link to the registration page.

    And this registration page is always in french, whatever the page we come from!!!

    This is a serious problem, and resolving it would mean a donation to you.

  25. squalyl
    Member
    Posted 2 years ago #

    Note that for ease of debug, the same problem exists with the english page

    english homepage: http://www.inspiredmelodies.com/en/
    protected page: http://www.inspiredmelodies.com/en/download/
    And the 'register' link points to http://www.inspiredmelodies.com/wp-register.php , which also displays... in french!!!

    Any help would be very greatly appreciated!

  26. RavanH
    Member
    Posted 2 years ago #

    Hi squalyl, do you have define('WPLANG', 'fr_FR'); in your wp-config.php maybe? And/or French set as the default language in the Polylang settings?

    The issue you are seeing should not be occurring on a clean WordPress installation. Maybe it is the plugin that allows for your login page customisation? Or the anti-spam question plugin?

    Disable those (or all except Polylang) and test again... Then re-enable one by one, testing each time to see when the issue comes back.

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • Polylang
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic

Tags