[wp-trac] [WordPress Trac] #41305: Add lazily evaluated translations

[WordPress Trac]

#41305: Add lazily evaluated translations
-------------------------------------------------+-------------------------
 Reporter:  schlessera                           |       Owner:
                                                 |  timothyblynjacobs
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.2
Component:  I18N                                 |     Version:  4.8
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch early dev-feedback needs-  |     Focuses:  rest-api,
  testing                                        |  performance
-------------------------------------------------+-------------------------

Comment (by TimothyBlynJacobs):

 I wanted to summarize what I think the most likely candidates for breakage
 are with the current patch version. This is mainly repeating @schlessera
 comment in #18.

 Strict comparisons with translated strings will no longer work as
 expected: https://3v4l.org/6CNqk

 This pattern is used in core for locale specific "settings". For instance:

 {{{#!php
 // In get_comments_number_text()
 'on' === _x( 'off', 'Comment number declension: on or off' )

 // In twentyseventeen_fonts_url()
 $libre_franklin = _x( 'on', 'Libre Franklin font: on or off',
 'twentyseventeen' );

 if ( 'off' !== $libre_franklin )
 }}}

 The second area is using lazy translated strings as array keys. For
 instance, `WP_Locale::init()`. Unfortunately, PHP doesn't coerce those
 objects into string array keys. https://3v4l.org/MRCuk

 For anyone using strict types, it will also cause a fatal error:
 https://3v4l.org/gU06F

 ----

 I'm not sure whether this should be considered an acceptable level of BC
 breakage. If not, I think we should reconsider using `_l` and `esc_attr_l`
 etc...

 This ticket would've solved the translating REST API requests issue, but
 that has been solved separately.

 Additionally, lazily translating every string isn't necessarily a
 performance boost. A string that is lazy requires an object instantiation.
 For more complex cases like `esc_html__()` and `esc_attr__()` it requires
 two object instantiations. Additionally there is a memory allocation in
 the cache pool, and a destructor routine that runs to clear the pool in an
 attempt to reduce total active memory. For strings that will get rendered
 or converted to a string in a request, this instantiation is wasted. I
 think more profiling is needed for how this impacts non REST API requests.

 If we were to use a specific lazy function, I imagine we'd change all the
 schema translations to be lazy loaded.

 ----

 Some other thoughts:

 Lazy translation functions would be easy to "polyfill" for later versions
 by just making them aliases for their `__` variants. So this wouldn't
 necessarily significantly hamper plugin adoption. There wouldn't be the
 performance benefits of course, but plugins could use it without having to
 do version checks all over the place.

 Also, now that we have `wp i18n`, adding new functions to be extracted for
 gettext might be less of an issue.

 ----

 If we do think this level of breakage is ok, then I think we want to
 commit this early and get feedback that way. The different callouts we've
 done have not gotten a lot of attention. We might have missed that window
 for 5.2 though.

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