Conversation
supportDear Pascal, I found this old topic that basically sums it up: https://wordpress.org/support/topic/not-working-for-wpamlia-and-borlabs-cache/ Even with most recent versions of WP, Preferred Languages and Borlabs Cookie the issue persists. I added German (formal) + German (informal) as site languages but Borlabs Cookie still seems to think the main site language is English. Disabling your plugin is the only remedy afaik in order to make Borlabs work as expected. But as Borlabs saves all the settings based on the current language, one needs to reconfigure all plugin settings again. Regards, Daniel
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.
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?
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.
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.
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.
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.
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, 10 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.
Screenshot A: https://share.cleanshot.com/bG6b0LyV WordPress settings BEFORE installing your plugin. Screenshot B: https://share.cleanshot.com/lGCSbkWG Value of WPLANG in the options -table. Screenshot C: https://share.cleanshot.com/CxGpCZtN After your plugin has been installed, and the languages have been added and saved. Screenshot D: https://share.cleanshot.com/2LHD7Qg2 The value of WPLANG is removed by your plugin. You can contact me at https://borlabs.io/support/ to receive a coupon for a license key.
Hi Pascal, I’ll sent you a user login for a DEV site that shows this behaviour if you like. If so, tell me where to send it to.
I dug a little deeper and I think your plugin is not removing the WPLANG value of the option, but is still responsible for removing it. I think it’s somehow related to the replaced <select> field on the WordPress settings page.
Email sent! I dug a little deeper and I think your plugin is not removing the WPLANG value of the option, but is still responsible for removing it. Hmm are you fetching that value using direct database queries? You will notice that calling get_option( 'WPLANG' ) will still return de_DE_formal as the value, so there shouldn’t be any breakage. But if you do direct queries or circumvent any filters that’s another story… In that case I can look into always persisting that value, no matter what.
Hey guys, just found that with most recent versions (WP + your plugins) this issue still didn’t seem to be resolved. But I found a little workaround (for existings sites being updated): Disable “Preferred Languages” temporarily Switch site default language back to intended language (German Formal here) Re-enable “Preferred languages” (old settings should be restored) That seems to do the trick in order for Borlabs Cookie 3.x find the correct default site language.
just found that with most recent versions (WP + your plugins) this issue still didn’t seem to be resolved. You might have seen that there hasn’t been a new release of the plugin yet, that’s why. The Borlabs plugin does some weird stuff, so the next Preferred Languages release will contain a workaround.
We don’t do weird stuff…we simply make our plugin compatible to the most used multilingual plugins WPML, Polylang and TranslatePress.
We are currently testing an upcoming update that includes a small adjustment to improve compatibility with Preferred Languages. Once all major multilingual plugins have been successfully tested, the change will be included in update 3.3.11, scheduled for release in early June 2025.
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.
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?
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.
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.
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.
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.
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, 10 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.
Screenshot A: https://share.cleanshot.com/bG6b0LyV WordPress settings BEFORE installing your plugin. Screenshot B: https://share.cleanshot.com/lGCSbkWG Value of WPLANG in the options -table. Screenshot C: https://share.cleanshot.com/CxGpCZtN After your plugin has been installed, and the languages have been added and saved. Screenshot D: https://share.cleanshot.com/2LHD7Qg2 The value of WPLANG is removed by your plugin. You can contact me at https://borlabs.io/support/ to receive a coupon for a license key.
Hi Pascal, I’ll sent you a user login for a DEV site that shows this behaviour if you like. If so, tell me where to send it to.
I dug a little deeper and I think your plugin is not removing the WPLANG value of the option, but is still responsible for removing it. I think it’s somehow related to the replaced <select> field on the WordPress settings page.
Email sent! I dug a little deeper and I think your plugin is not removing the WPLANG value of the option, but is still responsible for removing it. Hmm are you fetching that value using direct database queries? You will notice that calling get_option( 'WPLANG' ) will still return de_DE_formal as the value, so there shouldn’t be any breakage. But if you do direct queries or circumvent any filters that’s another story… In that case I can look into always persisting that value, no matter what.
Hey guys, just found that with most recent versions (WP + your plugins) this issue still didn’t seem to be resolved. But I found a little workaround (for existings sites being updated): Disable “Preferred Languages” temporarily Switch site default language back to intended language (German Formal here) Re-enable “Preferred languages” (old settings should be restored) That seems to do the trick in order for Borlabs Cookie 3.x find the correct default site language.
just found that with most recent versions (WP + your plugins) this issue still didn’t seem to be resolved. You might have seen that there hasn’t been a new release of the plugin yet, that’s why. The Borlabs plugin does some weird stuff, so the next Preferred Languages release will contain a workaround.
We don’t do weird stuff…we simply make our plugin compatible to the most used multilingual plugins WPML, Polylang and TranslatePress.
We are currently testing an upcoming update that includes a small adjustment to improve compatibility with Preferred Languages. Once all major multilingual plugins have been successfully tested, the change will be included in update 3.3.11, scheduled for release in early June 2025.