[wp-trac] [WordPress Trac] #56051: load_textdomain() cached for the better boot-up performance

[WordPress Trac]

#56051: load_textdomain() cached for the better boot-up performance
---------------------------+--------------------------
 Reporter:  itmapl         |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  6.1
Component:  I18N           |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  needs-refresh  |     Focuses:  performance
---------------------------+--------------------------

Comment (by adamsilverstein):

 Hi @itmapl - thanks for opening this ticket! `load_textdomain` caching
 seems like an important and worthwhile performance improvement we should
 try to land and the scope seems more contained than other tickets! I have
 some questions!

 Reviewing the patch you proposed in
 https://github.com/WordPress/WordPress/pull/600 both
 `load_textdomain_from_cache` & `cache_textdomain` use file based caching.
 If I understand this correctly, the goal is to have to load and process
 the language files once, so a persistent cache makes sense. I'm not sure
 how large the data is and if maybe using the core Transient API would be
 better here? Ideally using an existing caching API is preferable over
 writing files directly which might not work as expected.


 > What I've been thinking about is adding a cache clear after a language
 update via admin. This will give the way a user doesn't have to care about
 what is cached (and all the stuff to manage that) referring to l10n etc.
 All will be done under the hood.

 Caches would also need to get updated on core, plugin and theme updates
 where strings could potentially change. If core doesn't already have a
 "languages_updated" action maybe consider adding one.

 >  yet another approach to the problem. Probably the most fit with the WP
 core.
 https://github.com/WordPress/WordPress/compare/master...itma:WordPress
 :l10n-custom-action-filter
 >By adding an action hook and filter hook any plugin can hook into that
 and process it on its own way.

 I feel like the caching itself belongs in core if possible! Once we have
 that, For hooks, I definitely see value in a hook for "languages updated"
 and a way for developers to disable the caching entirely for their use
 case


 > The change to the core WP implementation will significally decrease the
 memory usage, and speeds-up the boot-up time

 It would be nice to add basic profiling information to the ticket with
 some before/after numbers for page load time and memory consumption so
 that we can proceed with a better understanding of the implications of the
 change. Let me know if you want some help with that!

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