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

WordPress Trac noreply at wordpress.org
Mon Oct 17 09:17:24 UTC 2016


#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
--------------------------------------+-----------------------------

Comment (by akirk):

 It is really great to see how this has been coming along. As i18n-calypso
 has been mentioned earlier as a comparable project, I’d like give a little
 insight into what we have done at Automattic with
 [https://developer.wordpress.com/calypso/ Calypso]
 ([https://github.com/Automattic/wp-calypso ongoing development in the
 open]). What is now i18n-calypso, was an integral part of Calypso before
 it was refactored into that new project.

 [https://github.com/Automattic/i18n-calypso i18n-calypso] largely consists
 of two components. A CLI utility that extracts the strings, and a library
 that handles loading and output of translations (with some hooks to make
 things like the [https://github.com/Automattic/community-translator
 Community Translator] possible).

 In i18n-calypso we chose the path to not simply convert the Gettext
 functions to JavaScript but [https://github.com/Automattic/i18n-calypso
 #translate-method we combined it into one called `translate()`] (which
 internally currently still uses Jed and therefore ends up being a wrapper
 around it). We actually went so far as to integrate the `replace()`
 [https://github.com/Automattic/i18n-calypso/blob/master/lib/index.js#L254
 in our translate function] (using an `args` object).

 I was wondering why you chose the current approach (i.e. several functions
 "ported" from PHP), and I assume it’s mostly because of this:

     We agreed that it makes most sens to use Jed's gettext functions and
 parse translatable strings inside the JavaScript files, like we already do
 with PHP.

 @ocean90 has proposed a solution that [https://github.com/ocean90/wp-i18n-
 tools/pull/1 parses and tokenizes JavaScript in PHP] in the end, so I am
 not sure if that is still a deciding factor? (Could you give some details
 on why you chose not, resp. were not able, to use `xgettext`?)

 In i18n-calypso, to extract the strings, we [https://github.com/Automattic
 /xgettext-js parse JavaScript using JavaScript]. The JavaScript parser
 written in PHP that was used in the POC above
 [http://timwhitlock.info/blog/2009/11/jparser-and-jtokenizer-released/ was
 released in 2009] and I don’t see it having been updated since. i18n-
 calypso uses [https://github.com/babel/babylon babylon] which was updated
 2 days ago and can do ES2017 and parse JSX.

 What to make of all of this? Deciding whether to revamp the approach and
 use a single `translate()` function as i18n-calypso does, depends on
 factors that you are likely more familiar with than I am. I think a common
 (compatible) format between WordPress (related) projects is favorable,
 though.

 Either way, I see the opportunity to make use of the
 [https://github.com/Automattic/i18n-calypso/tree/master/cli tools that
 exist in i18n-calypso for extracting the strings], and maybe even use
 i18n-calypso for handling the translation altogether--possibly there is a
 need to adapt it for WordPress Core (such as adding support for text
 domains and removing the dependency on React) but it’s something that I
 think is worth discussing.

 There is a point in having `makepot.php` be able to do both PHP and
 JavaScript (as in the [https://github.com/ocean90/wp-i18n-tools/pull/1 POC
 implementation]) but I see problems regarding newer developments in
 JavaScript (you’ll want to be able to extract translatable strings from
 plugins’ JavaScript even if they use ES6 or newer), so I think it should
 be considered to extract JavaScript strings in a separate step, in
 JavaScript.

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


More information about the wp-trac mailing list