For now I will switch back to previous Loco Translate Plugin version or disable it, so the error won’t be visible in live page.
Rolled back to v.2.6 works like a charm!
Plugin Author
Tim W
(@timwhitlock)
Please read FAQ – https://localise.biz/wordpress/plugin/faqs/early-domain-loading
I would like to know how rolling back Loco Translate removed this problem. Did you also roll back WordPress? The error message comes from WordPress core, and the root cause comes from whatever requested a translation in the checkout-plugins-stripe-woo domain.
I read it before posting. I already assumed that there will be no real solution, this is more for other users to know that they can switch back to previous version and everything will work.
Plugin Author
Tim W
(@timwhitlock)
they can switch back to previous version and everything will work.
Previous version of what? Did you also roll back WordPress?
I downloaded and installed version 2.6.x of your plugin. Errors went away and checkout works. I will wait for WordPress updates or theme updates and only then update to version 2.7 to check.
Plugin Author
Tim W
(@timwhitlock)
I need to know how it’s possible that my 2.7 update changes the behaviour of another text domain being loaded too early.
The 2.7 update contains a critical fix that allows custom translations to be loaded when early loading has prevented them from working. If that same fix causes other problems for other people, then neither version will work for everyone.
I’m on my own here trying to reproduce extremely nuanced issues. Can you please post details of what translation files you have installed, and anything else that I’ll need to reproduce the problem (other translation plugins, language switchers, etc..)
Hello:
Active plugins for now:
Aktīvie spraudņi (11)Advanced Woo Labels ILLID rakstīja – 2.10Starter Templates Brainstorm Force rakstīja – 4.4.11Checkout Plugins – Stripe for WooCommerce Checkout Plugins rakstīja – 1.10.1Decorator – WooCommerce Email Customizer WebToffee rakstīja – 2.0.0Loco Translate Tim Whitlock rakstīja – 2.6.14MultiParcels piegāde WooCommerce MultiParcels rakstīja – 1.19.7SureForms SureForms rakstīja – 1.3.0Spectra Brainstorm Force rakstīja – 2.18.2Checkout Field Editor for WooCommerce ThemeHigh rakstīja – 2.1.1WooCommerce Automattic rakstīja – 9.6.0WP-Optimize – Clean, Compress, Cache TeamUpdraft, DavidAnderson rakstīja – 3.8.0
Theme Astra:4.8.10
Translation is made from english to latvian for these 3 items:
WooCommercewoocommerce24 janvāris, 2025 3:34 pm1Astraastra22 janvāris, 2025 9:08 pm1Checkout Plugins – Stripe for WooCommercecheckout-plugins-stripe-woo21 janvāris, 2025 10:13 am1
The error comes from Stripe translation in latvian (4 strings), I will remove it and update Loco Translate to check if this is the problem.
Plugin Author
Tim W
(@timwhitlock)
Please show what translation file or files you have in Latvian. Custom, System, etc.. Also an example string please.
Hello! I deleted the Latvian translation I made for Stripe plugin and updated Loco Translate. Everything works. I will leave that plugin untranslated for now.
Plugin Author
Tim W
(@timwhitlock)
If you run Loco Translate 2.7.0 (or the current dev version of 2.7.1) you can remove the “fix” using the loco_unload_early_textdomain filter. If you return false for the checkout-plugins-stripe-woo then it won’t be unloaded. I’d be interested if this makes a difference.
But I can’t understand what caused this. The Stripe plugin takes time to load itself, maybe this is the problem. The live site with Stripe loading: https://irisi.dynamite.lv/checkout/
Plugin Author
Tim W
(@timwhitlock)
I’m glad it works for you, but I need to implement an actual fix that works for everyone or this will never end. I’ll appreciate your help, because setting up a shop and Stripe payments etc.. is just too much effort to reproduce a simple problem.
After the update my site crashed with a HTTP 503 error and no entries in the PHP log. So I had a really hard time finding the problem. After a lot of testing I found out that the problem was a call of the ACF function get_field() inside the locale filter like this:
function set_locale_frontend($locale)
{
$default_locale='de_DE';
if(is_admin()) return $default_locale;
else $site_locale=get_field('site_locale', 'option');
}
add_filter('locale', 'set_locale_frontend');
The solution was to use get_option('options_site_locale') instead. Probably ACF isn’t fully initialized when the locale filter is fired.
Maybe this helps someone with similar issues.
