[wp-trac] [WordPress Trac] #39210: switch_to_locale() unloads all plugin and theme translations

[WordPress Trac]

#39210: switch_to_locale() unloads all plugin and theme translations
-------------------------------------------------+-------------------------
 Reporter:  gchtr                                |       Owner:  ocean90
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.1
Component:  I18N                                 |     Version:  4.7
 Severity:  normal                               |  Resolution:
 Keywords:  has-unit-tests has-patch needs-dev-  |     Focuses:
  note                                           |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:67 ocean90]:
 > Replying to [comment:66 flixos90]:
 > > * When using the en_US locale, `load_textdomain()` is (unnecessarily)
 called a ton of times (107 times in WP 6.1-RC2 vs 3 times in WP 6.0.3).
 >
 > Assuming you have no other plugins active, could you explain what calls
 these are? And why there are unnecessary?

 I used a vanilla WordPress site with no plugins and Twenty Twenty-One,
 with just the initial Hello World post. Only the default and
 twentytwentyone text domains are used in this context, but the commit here
 results in load_textdomain() to be called 107 times in one page load, even
 though all the site is en_US (no locale switching happening at all). So
 this is clearly a bug that needs to be addressed.

 > > * The regression is only present on en_US sites. For sites that use a
 locale that typically has translation files present, performance remains
 basically as before.
 >
 > That's actually a good point since the changes here will significantly
 improve the translation handling
 [https://wordpress.org/about/stats/#locales for the majority of our user
 base]. ''If'' there's some tradeoff this should also be taken into
 consideration.

 It makes sense that this is a trade off. I would like to see some data
 though under which conditions the commit improves translation handling and
 how (much).

 > I think for the moment we should identify what the problem actually is
 and if it's not something that can be fixed before the release and/or in a
 follow-up release.

 As mentioned, I'm open to fixing this prior to release if feasible. But
 the data I shared proves the regression coming from the commit. Without
 having opposing data that would quantify any performance ''benefit'' for
 non-en_US sites, this either needs to be fixed or reverted prior to
 release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39210#comment:70>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform