[wp-trac] [WordPress Trac] #63933: Add performance optimization for block pattern translations

WordPress Trac noreply at wordpress.org
Fri Sep 5 09:54:04 UTC 2025


#63933: Add performance optimization for block pattern translations
-------------------------------+------------------------------
 Reporter:  rahultank          |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  I18N               |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:  performance
-------------------------------+------------------------------

Comment (by rahultank):

 Hi @swissspidy , thank you for the feedback and component correction to
 I18N!

   You're absolutely right about WordPress's translation caching being
 highly optimized. I apologize for the
   misleading description about "database queries" - that was incorrect.

   Let me clarify the actual issue I observed:

   Specific Problem:
   While working with sites that have 20+ block patterns with multiple
 translatable strings, I noticed repeated
   __() function calls during pattern rendering, not database issues.

   Reproduction Steps:
   1. Create a WordPress site with 3+ language packs installed
   2. Register 20+ block patterns each containing 5-10 translatable strings
   3. Load the block editor (especially pattern inserter)
   4. Monitor with Query Monitor or Xdebug profiler

   What I Actually Observed:
   - Same translation strings called multiple times across different
 patterns
   - Function call overhead accumulating with many patterns
   - Not database performance, but PHP function call efficiency

   Example:
   // Pattern A calls: __('Read More', 'default')
   // Pattern B calls: __('Read More', 'default')
   // Pattern C calls: __('Read More', 'default')
   // = 3 separate function calls for identical string

   My Question:
   Is this actually a performance concern worth addressing, or is
 WordPress's existing optimization sufficient
   even for sites with many patterns?

   If this isn't a real issue, I'm happy to close this ticket and focus on
 areas where contributions would be
   more valuable.

   Alternative Focus:
   Given your I18N expertise, are there any current i18n areas in WordPress
 core where contributions would be
   more beneficial?

   Thank you for your time and guidance!

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


More information about the wp-trac mailing list