I don‘t know what that plugin does or how it works, but it sounds like it does unusual things in WordPress. Have you reported this to that plugin already? If not, I recommend doing that first.
Ben
(@benbornschein)
The language is determined by get_locale() when WordPress is loading the plugins and can only be change when using supported plugins like WPML, Polylang, Weglot, Falang oder TranslatePress.
Hi!
That‘s not true. The language can be changed even multiple times during a request using switch_to_locale.
Worth noting that Preferred Languages filters get_locale and supports locale switching too. It has a robust set of tests for all of that.
Not sure what yor comment is about that. Are you doing something special in the load process? Are you saving translated strings in the database?
Ben
(@benbornschein)
Since WordPress has not native multi language support, we have to do it this way to be compatible with the mentioned plugins. I also think that m0n0mind has not configured their website correctly, because for our plugin the language is determined by the websites content and not the user’s language.
So I disabled all plugins except both involved, switched to default theme, resaved general (language) settings, changed language order in preferred languages, confirmed no user defined language override is active etc.
But still, the issues persists. Borlabs “thinks” the site language is (default) english. So only disabling Preferred Languages” seems to fix it for me.
Ben
(@benbornschein)
What is your goal that you would like to achieve with “Preferred languages”?
What language is the content of your website in?
At the time the site was set up, preferred languages helped in loading fallback languages for plugins that didn’t support formal german language. Right now I’m not sure if this is still needed though. Would need more testing and checking which plugins we had this issue with (can’t remember as it’s been some years since).
So it’s not really a breaking issue here. But I thought to bring this to your attention again given that the linked thread above shows that the issue persists for a long time already. If it’s hard to track down or fix, skip it.
Ben
(@benbornschein)
If your website is set to German, our plugin (Borlabs Cookie) should be able to recognize German as a language. Please ensure you are using the latest version of Borlabs Cookie 3.x and check in our dashboard which language has been recognized by our plugin.
Hi Ben,
thanks for your answer. I checked this of course and apart from Borlabs Cookie, everything works as expected so far. Most recent versions used.
Ben
(@benbornschein)
You can create a support request and we can look into it.
Borlabs Cookie is a commercial plugin so I cannot test it.
If it doesn’t support plugins like Preferred Languages (which will be merged into core eventually too), then this needs to be addressed there.
Opening a support request with them sounds like the best course of action.
Closing this topic accordingly.
Hi Pascal,
Ben from Borlabs had a deeper look at it.
According to him, your plugin deletes the WPLANG db options entry, so Borlabs Cookis just falls back to default en_US.
He recommends saving at least the first choice of the plugins’ language selections to the option instead.
That‘s just plain wrong, the plugin doesn‘t delete any options. In fact, it _filters_ the option to return the first choice in the list at runtime.
Ben
(@benbornschein)
In your functions.php in line 385 and 413 you call update_option( 'WPLANG', '' ); which deletes the original value and in your entire code you will never restore this value. But this option value is used by WordPress’s get_locale() function.
-
This reply was modified 1 year, 7 months ago by
Ben.
These two lines set the language to en_US when you clear the list of preferred languages. That‘s the same as when you mamually set the language to en_US in the settings. The option is not updated otherwise. The value is always fresh though by filtering the option value (line 448 onwards).
If you have any minimum viable reproduction steps for a bug involving PL that can be verified without purchasing a plugin, that would be helpful.
