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

 Thanks for chiming in @aduth, great to have your input here. :)

 Replying to [comment:65 aduth]:
 > 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.

 (cc @ocean90 for input on whether that's a good idea)

 > 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?

 The problem with Intl is that it's ICU-based, and requires browser support
 for the language. This becomes an issue if we have localisation for a
 language that the browser doesn't (or vice versa, but that's unlikely to
 be possible to actually hit), plus it doesn't integrate with our existing
 gettext-based system, so there may be mismatches. I think consistency is
 super important here: our JS needs to always be from the mindset of
 progressive enhancement (even if that's not always the case).

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