[wp-trac] [WordPress Trac] #62487: JIT translations prevents swapping or changing translation files

[WordPress Trac]

#62487: JIT translations prevents swapping or changing translation files
--------------------------+-------------------------
 Reporter:  desrosj       |      Owner:  swissspidy
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  6.7.2
Component:  I18N          |    Version:  6.7
 Severity:  normal        |   Keywords:  needs-patch
  Focuses:                |
--------------------------+-------------------------
 #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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62487>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform