[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 aduth):

 Forgive my joining late in this discussion. In anticipation of the
 upcoming dev chat about consolidating future JavaScript efforts, I wanted
 to review this ticket and share a few of my own notes and experiences.

 In my being oblivious to the existence of this ticket, I'd separately put
 together [https://github.com/WordPress/gutenberg/tree/master/i18n an i18n
 solution for the Gutenberg project], but I'm happy to see it aligns almost
 identically with what's currently proposed here. Using Jed is an obvious
 choice; workflow, integration with GlotPress, and making strings available
 in the browser are admittedly harder problems.

 Despite having contributed to Calypso's i18n solution, I still find that
 the naming consistency here between PHP and JS functions will make for a
 nicer transition for developers familiar with the former (I think this is
 the "one function to rule them all" argument for `__()` et al.?). So I
 don't personally see a reason to change APIs are they're proposed
 currently.

 Reinforcing a few points made earlier:

 - I agree with @jdgrimes (comment:53) that making `esc_attr__` functions
 available will only encourage poor security practices and I'd suggest they
 be excluded.
 - I agree with @akirk (comment:55) that supporting latest language
 features of JavaScript in string extraction will be easiest using
 JavaScript parsers like [https://github.com/babel/babylon Babel's Babylon]
 (or [https://github.com/ternjs/acorn Acorn], or
 [https://github.com/eslint/espree Espree], or
 [https://github.com/jquery/esprima Esprima]), which tend to be well-
 maintained and follow closest to the bleeding edge.

 Unlike `xgettext-js` which uses a separate CLI process to call to
 Babylon's API directly for extracting strings, in Gutenberg I'd opted
 instead to explore a
 [https://github.com/WordPress/gutenberg/blob/master/i18n/babel-plugin.js
 custom Babel plugin] which extracts strings during the same build step as
 the application itself. Nothing about this necessitates opting in to
 ES2015+ or JSX syntax, but it was a convenient option for us to guarantee
 parsing is consistent between string extraction and the build.

 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.

 In consideration of some of the more recent discussions about browser
 support, it might be worth discussing what role the
 [http://caniuse.com/#feat=internationalization browser native i18n APIs]
 could have on what should be implemented here. For example, do we need
 `wp.i18n.numberFormat` if [https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat
 Intl.NumberFormat] is already in scope?

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