zitrusblau

Thanks, fixed now!

Sorry, but this fix was not included in 2.3.5.

Thanks!

Still having this problem with empty language select boxes in plugin settings then (https://jumpshare.com/v/SEl5yTmdWwCdoBIzK72P) and this thing:

Ok, and then there’s another small issue. The selected languages on settings page are correctly translated but those in the editor UI are not:

https://jmp.sh/YM5bqwOS
https://jmp.sh/UYx0fand

Would you verify the suggested fix and include it in the next plugin update?

Hey, any news in this regard? The issue is not really resolved…

Yeah, I’m not sure, maybe it’s not relevant for translating through the API.

I’ll try to find a solution with the plugin author. Thanks again for looking into this!

I checked again more in depth now. Of course disabled all plugins and used WP default theme again.

The cause of the empty select labels is actually not the plugin “Preferred Languages” but solely selecting “de_DE_formal” as the main site language. Switching it to “de_DE” will show the labels again.
Please make sure to enable “Deutsch (Sie)” as the main site language not “Deutsch” as shown in your screenshot to replicate the issue.

We use “Preferred Languages” to provide a fallback in case plugins don’t support the formal language code btw. This works most of the times.

https://jmp.sh/jZ8N8xMv

I then fixed it by removing the ‘_formal’ part of get_locale() in deepl-configuration.class.php around line 196:

static function DefaultsISOCodes() {
	$locale = get_locale();
	$locale = str_replace('_formal', '', $locale );
...
}

However, I dunno if this is the right approach in order to correctly process and translate content written in formal language with Deepl. Maybe this is not even relevant for the API-calls.

After this fix, I was finally able to translate some content. Yaih!

Ok, and then there’s another small issue. The selected languages on settings page are correctly translated but those in the editor UI are not:

https://jmp.sh/YM5bqwOS
https://jmp.sh/UYx0fand

Hey,

no problem with the return value of get_locale(), I get a valid string “de_DE_formal”.
It’s actually this line in your code which is causing trouble:

$locale = substr( '_formal', '', $locale );

please check https://www.php.net/manual/en/function.substr for reference. 2nd parameter ($offset) needs to be string.
So I fixed it for me like this:

$locale = str_replace('_formal', '', $locale );

Interesting!
WP Deepl has some extra settings to handle formality level somehow but I dunno how it handles this case.
We use “de_DE_formal” here.

Let’s see what the plugin author is saying.

Thanks!

• This reply was modified 1 year, 4 months ago by zitrusblau.

Sorry to bother again. In order to check if it’s only happening on certain steps involved I proceeded the way you wrote earlier:

I created a German article from a French article, saved the draft, then translated from FR to DE.
I had no problem.

I added a native english content then duplicated that content for a german translation, saved this as draft but had the exact same error.

BTW: I found that when saving a draft the plugin’s metabox tells me to save or publish the post first (via block editor). Need to reload the editor view in order to show the translation interface.

Thanks for your fast response. But this raises another issue after updating:

production.ERROR: substr(): Argument #2 ($offset) must be of type int, string given {"userId":1,"exception":"[object] (TypeError(code: 0): substr(): Argument #2 ($offset) must be of type int, string given at /site/public/wp-content/plugins/wpdeepl/deepl-configuration.class.php:108)

I’d suggest to use str_replace() instead of substr() here.
Did that to fix it temporarily for my local test site and tried to translate again: https://jmp.sh/SvmB6ad1

This gives this warning then:

production.ERROR: Array to string conversion {"userId":1,"exception":"[object] (ErrorException(code: 0): Array to string conversion at /site/public/wp-content/plugins/wpdeepl/client/deeplapi-translate.class.php:154)

And still, the language select boxes on settings page seem to be empty:

https://jmp.sh/iWZx4K4l

Just checked the plugin settings again and found a setting for default formality level which I set to formal. But then the same error comes up as noted above and I’m unable to access this settings page now.
Also the select dropdown field labels are totally empty. Values are set but since there’s no label, the fields seem empty even though they’re selectable.

We’ve found a similiar issue using coblocks.

Just filed an issue on their github repo:
https://github.com/godaddy-wordpress/coblocks/issues/2321

Hey,
we have this issue as well using php-cli to run wp-cron periodically.

I solved it for us by adding this to line 112 (in function redirect() {})

if (!isset($_SERVER['HTTP_HOST']) || (isset($_SERVER['SCRIPT_FILENAME']) && $_SERVER['SCRIPT_FILENAME'] == 'wp-cron.php')) {
return;
}

I leave it to the developers to decide which fix is more generic. Please provide a fix. Thanks!

• This reply was modified 3 years ago by zitrusblau.
• This reply was modified 3 years ago by zitrusblau.