[wp-trac] [WordPress Trac] #20491: Introduce some JavaScript i18n functions

[WordPress Trac]

#20491: Introduce some JavaScript i18n functions
--------------------------------------+-----------------------------------
 Reporter:  johnbillion               |       Owner:  swissspidy
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  Future Release
Component:  I18N                      |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  javascript, rest-api
--------------------------------------+-----------------------------------

Comment (by swissspidy):

 > > I'm curious about the decision to use a separate JSON-formatted export
 of strings, versus preparing an object for Jed on the fly. So far it's
 worked well enough for us to generate the object from the return value of
 [https://developer.wordpress.org/reference/functions/get_translations_for_domain/
 get_translations_for_domain]
 ([https://github.com/WordPress/gutenberg/blob/3d9b30f26788071ca9b650c56e35d3ffe0a5a622/index.php#L102-L133
 see source]). That said, we've been fortunate to disregard handling
 multiple domains or distinguishing between strings sourced from PHP vs.
 JS, so there may well be other considerations we're overlooking.
 >
 > I agree; doing this on the fly I think has better compatibility, and
 ensures that PHP and JS both stay in sync correctly. The only potential
 concern is that we're going to pass a ''lot'' of strings doing it this
 way, whereas building separately can allow us to just pass those that are
 actually required. We could potentially use a different domain for JS to
 get around this.

 Plugins in the Plugin Directory are required to have exactly one text
 domain becuase of various reasons and limitations in both core and
 WordPress.org. I don't think this will change anytime soon. Plus, if we
 can build something in a way developers  don't have to worry about it, we
 should pursue it.

 Projects like Jetpack easily have hundreds of translatable strings.
 Passing all the strings will be too much for them, and separating JS
 strings on the fly would have a bigger performance impact than just
 providing a JSON file right from the beginning. The language pack system
 with its update system has been reliable for so long now that I don't see
 any harm in providing separate files.

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