JIT translations prevents swapping or changing translation files

[desrosj]

#62337 resolved a handful of bugs related to the just-in-time translation changes that shipped in 6.7 (see #44937/[59157]).

There was one outstanding reported edge case issue that remains unsolved as reported by @timwhitlock. Since there were fixes shipped for #62337 in 6.7.1, that has been closed out and this ticket can be used to continue discussion related to the last issue.

Here are the relevant bits describing the problem:

It's taken me a few days to fully appreciate the impact of this.

I'm advising my plugin users to roll back to 6.6 and wait for 6.7.1. In the mean time, any components that use translations too early need to be identified and fixed

​https://wordpress.org/support/topic/wordpress-6-7-major-issue-loading-custom-translation-files/

It would have been helpful if the early loading notice (which is great) had been introduced some versions prior to the sudden change in load_*_textdomain, but that's the benefit of hindsight. The relationship between premature JIT loads, and explicit loading of custom translation paths was probably not obvious.

comment:32:ticket:62337

It looks like the patch only unloads the text domain if it's NOOP_Translations. That means authors still can't override GlotPress translations that have been JIT loaded. You may think they shouldn't need to, but why prevent them doing so?

comment:34:ticket:62337

My plugin lets users override GlotPress translations with their own custom translation files. It does this by listening on the load_textdomain action hook. When the original MO is requested, a custom file is loaded if one exists. If both exist, they are merged.

You can see the code if you like here: ​https://github.com/loco/wp-loco/blob/master/src/hooks/LoadHelper.php

WP 6.7 breaks this function for the reasons well noted in this thread. Premature JIT invocation is a pervasive problem, and one out of my control. With 1+ million installs, you can imagine my inbox is full of some quite angry people.

So to answer your question - I can't call unload_textdomain, because my code won't run until hooks fire. Which they now don't. Only the text domain provider can make that fix. My users will be lucky if that happens fast enough, or at all.

In order to restore previous functionality myself, I would have to forcefully unload all text domains when my plugin starts up. I don't want to do that, partly for performance. But if 6.7.1 doesn't rectify the issue I may have to.

It's worth noting that unloading NOOP translations does indeed cover a lot of the most common cases, but not all of them. I don't see a good reason to be so selective, other than to protect the performance gains for which this change was [I assume] primarily made. I respect the need for performance, but not at the expense of broken websites.

Ideally I'd like to see an action hook that gets fired for load_theme_textdomain and load_plugin_textdomain. This would allow people to fix the problem as they see fit without compromising performance for everyone else.

Sorry for such a long answer, but I've lived and breathed this problem for the past week.
Thanks for your consideration!

comment:37:ticket:62337

There is nothing to hook into. If JIT loading has already been done, then no hooks fire at all when calling load_plugin_textdomain.

comment:39:ticket:62337

[reteinformatica]

I have problems after upgrading to version 6.7. I had initially solved it, although sometimes the errors would come out but sporadically, by setting the backfront to English instead of Italian which is my language.
After the 6.7.1 update everything got worse, error after error on both the backfront and the site.
My site: ​https://todabe.it/

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the complianz-gdpr domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /xxx/xxx/public_html/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the elementor-pro domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /xxx/xxx/public_html/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wpr-addons domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /xxx/xxx/public_html/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wpr-addons domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /xxx/xxx/public_html/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wpr-addons domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /xxx/xxx/public_html/wp-includes/functions.php on line 6114

Warning: Cannot modify header information – headers already sent by (output started at /xxx/xxx/public_html/wp-includes/functions.php:6114) in /xxx/xxx/public_html/wp-admin/includes/misc.php on line 1438

Warning: Cannot modify header information – headers already sent by (output started at /xxx/xxx/public_html/wp-includes/functions.php:6114) in /xxx/xxx/public_html/wp-includes/functions.php on line 7137

Deprecated: Calling get_class() without arguments is deprecated in /xxx/xxx/public_html/wp-content/plugins/google-site-kit/third-party/google/apiclient/src/Http/REST.php on line 49

Warning: Cannot modify header information – headers already sent by (output started at /xxx/xxx/public_html/wp-includes/functions.php:6114) in /xxx/xxx/public_html/wp-admin/admin-header.php on line 9

[NikoV]

Hopefully this would get fixed. We have many users reporting strings not translating since the original used way to translate or change strings has been. Just duplicate the original files and run the translation from /loco/ file. This has been working for years and quite many people have been using it and have also made some of their own modifications.

Now the regular use case would be to copy the original. Set it to system folder. Then do another copy of that and do the string changes there. This isn't that userfriendly for folks that have been doing translations.

[swissspidy]

@reteinformatica This is not a bug in WordPress. As the message says, some plugins are loading translations too early, so this needs to be fixed in the plugins. AFAIK the Complianz plugin is already working on fixing theirs. For other plugins, you can point them to ​https://make.wordpress.org/core/2024/10/21/i18n-improvements-6-7/ so they can learn how to mitigate the issue on their end.

[swissspidy]

@timwhitlock Just checking in here, I see that you made a couple of new releases on your end in the meantime. What's the current status, which bugs are you still seeing (if any)?
I'm now back from vacation and eager to fix any remaining blockers.

[reteinformatica]

Replying to swissspidy:

@reteinformatica This is not a bug in WordPress. As the message says, some plugins are loading translations too early, so this needs to be fixed in the plugins. AFAIK the Complianz plugin is already working on fixing theirs. For other plugins, you can point them to ​https://make.wordpress.org/core/2024/10/21/i18n-improvements-6-7/ so they can learn how to mitigate the issue on their end.

Ok, I understood, thank you.