• Resolved joroabv

    (@joroabv)


    The plugin uses the site language to display its settings instead of the current logged in user profile language setting as it should be.

Viewing 15 replies - 1 through 15 (of 16 total)
  • Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    Thanks for your message.

    Just so I can be sure of the exact settings, please can you paste the link to the page you’re referring to? You only need to paste everything after the /wp-admin/ part of your URL.
    Once I have this, I can investigate.

    Thread Starter joroabv

    (@joroabv)

    Well … any URL that has “?post_type=bnfw_notification” in it and the pages linked on those pages. Simply the whole plugin backend uses the site language instead of the current user profile language.

    Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    This should have been fixed in version 1.9:

    Fixed: All BNFW screens are now translated using the language the user has set as opposed to the site language.

    Can you confirm you’re using the latest version of BNFW and WordPress?

    Thread Starter joroabv

    (@joroabv)

    @bnfw I’m running 1.9.1 and unfortunately it is not fixed. Main site language – Dutch, my profile language – WordPress default English. Whole backend in English as expected, only BNWP is in Dutch (incl. left menu items).

    Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    Ok, thanks. I’ll need to do some testing.

    In the meantime, can you check you have the English translation for BNFW in your wp-content/translations folder? It’s possible that if it hasn’t been downloaded, it’s the rason why it’s not showing.

    Thread Starter joroabv

    (@joroabv)

    @voltronik nope, only the nl_NL. But isn’t it normal, since the English is the default WP language. As far as I see – other plugins (that do work fine) also have their NL translations only.

    Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    Thanks for confirming.

    I’ve now tested and it appears it works one way (English to another language) but not the other (another language to English).

    I’ve logged this as a bug and should have this fixed in the next release.

    • This reply was modified 2 years, 1 month ago by bnfw.
    Thread Starter joroabv

    (@joroabv)

    ok, thanks. Looking forward to it.

    Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    Just letting you know this should have now been fixed in the latest version, released this week.

    Thread Starter joroabv

    (@joroabv)

    Hi,

    I noticed the update a few days ago and the changelog, but didn’t had the time to give you my feedback earlier. I short and unfortunately – it is not :-).

    I had this with another plugin – Simple Local Avatars and the guys there managed to solve it at the end but it was a pain. Basically – WordPress caches the user locale along the whole user and if you call it too early – it causes a mess. Not sure it is the same in your case but here’s the github issue where we led the discussion, it might eventually help you to solve it too :

    https://github.com/10up/simple-local-avatars/issues/157

    More specifically :

    https://github.com/10up/simple-local-avatars/issues/157#issuecomment-1320449223

    https://github.com/10up/simple-local-avatars/issues/157#issuecomment-1320839481

    Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    Thanks for the feedback.

    I’ve checked this and can’t replicate the issue you’re having after this release.

    If the site language is set to French, for example, then the WP Admin, including BNFW is in French. If I change my language to something else, such as English or German, when editing my profile, BNFW now appears in the language I have chosen where previously, it was still showing in the site language, and not the user’s chosen language.

    Are you testing it a different way? If so, please let me know so I can re-test.

    Thread Starter joroabv

    (@joroabv)

    No, you’re testing properly. Then it maybe that there is another plugin in my setup that breaks this. As you probably saw in the discussion – one is enough to partially break the whole backend language setup. I’ll go through all of the plugins, I’m using (which are a lot) and come back to you with the results.

    Thread Starter joroabv

    (@joroabv)

    So, here my findings – there are indeed two other plugins that trigger 'get_user_locale()' too early, but still – they do not cause the issue with BNFW. Even when I disable them and BNFW becomes the first to call 'get_user_locale' (I’m setting a breakpoint to check who gets there first) – I still see the wrong language loaded as it happens too early on BNFW load.

    I permitted myself the freedom to temporarily alter your code, namely – I changed the bnfw.php 'load_textdomain' function, by putting the 'load_plugin_textdomain' function in the WP 'init' action like this :

    public function load_textdomain() {
    // Load localization domain.
    $this->translations = dirname( plugin_basename( FILE ) ) . '/languages/';
    add_action('init', function() {
    load_plugin_textdomain( 'bnfw', false, $this->translations );
    });
    }

    Now, this works perfectly fine at first glance, but I did it only as a proof of concept. I’m not sure if it is actually the proper thing to do in order to fix this, but I hope it gives you some direction on what is happening and how it can be fixed eventually. Unfortunately – I couldn’t sort out any particular reason why it is fine at your place and works wrong at mine.

    Plugin Author bnfw

    (@voltronik)

    Hi @joroabv,
    I’ve tried this but having a hard time trying to get this to work. When using your method, it appears to work in one direction and not in the other (site language and profile vs profile and site language).

    It may have to do with transients or caching and it might be worth trying to deactivate the plugin and reactivate it with deleting transients in between to see if it helps.

    If I can’t find a solution it might be that you have to continue with your modifications in the plugin that work well for you but this will mean re-adding them on each plugin update.

    Let me know how you get on.

    Thread Starter joroabv

    (@joroabv)

    Yeah, well … as I said – it was just an experiment. Yet, I did it this way just because I was not brave enough to do this :

    /**
    * Fire up the plugin.
    */
    add_action(
    'plugins_loaded',
    function() {
    BNFW::factory();
    },
    1
    );

    … and this is how I actually solved the issues I had with the plugin, I’m writing. This one seems to work for me just like the other solution and since you have no stuff happening at ‘plugins_loaded’ It might well work overall, but you have to try it.

    I don’t know your code, so if you rely on some initializations before ‘plugins_loded’ it is a no go, of course, but if not – it definitely can be the right thing to do. You see – this is wrong by design in WordPress imo – you simply can’t use the user locale before ‘plugins_loaded’ and anyone trying to do so will fail miserably.

    If you’re willing to try it and If it still fails for you – let me know how exactly it fails and I’ll keep looking for a solution.

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Plugin settings do not respect profile language’ is closed to new replies.