[wp-trac] [WordPress Trac] #22229: Plurals in JavaScript

WordPress Trac noreply at wordpress.org
Mon Oct 27 00:12:49 UTC 2014


#22229: Plurals in JavaScript
-------------------------------------------------+-------------------------
 Reporter:  nacin                                |       Owner:  nbachiyski
     Type:  enhancement                          |      Status:  accepted
 Priority:  low                                  |   Milestone:  4.1
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-        |     Focuses:
  refresh                                        |
-------------------------------------------------+-------------------------

Comment (by nbachiyski):

 At contributor day we sat with Eric Lewis and went through the patch. To
 make the decision whether to commit it or to simplify it, here are some of
 the design trade-offs we were facing in the form of two implementation
 options:

 Option 0. (this patch)

  * A developer needs to only one function and to use it at
 `wp_localize_script` calls: `key => _n_js( singular, plural, domain )`
  * Using the plurals from JavaScript is incredibly easy, just call the
 value with the number as an argument to get the proper pluralized
 translation: `ScriptData.pluralValue(5)`
  * Allows anybody to add “inline” scripts and styles without a source
 file. Think `document.getElementById( 'username' ).focus();`. I am not
 sure how useful this will be in the future, may be YAGNI, outside of this
 case.
 * Allows anybody to add any literal JavaScript as part of the
 `wp_localize_script` array: `key => wp_js_make_literal( text, deps )`. See
 [http://wordpress.stackexchange.com/questions/8655/pass-object-json-to-wp-
 localize-script this post] for a use-case. Also remember
 `l10n_print_after`? ;-)

 Option 1. (possible simpler implementation)

  * Adding a plural via `wp_localize_script` is still simple:
 `wp_localize_script` calls: `key => _n_js( singular, plural, domain )`
  * Instead of adding a general method for adding literal JS inside
 `wp_localize_script`, we could make `_n_js` return a special structure and
 then developers in JS could call a special function, let’s say:
 `wp.i18n.plural( ScriptData.pluralValue )`. I think this is much worse
 developer experience, because they need to remember even more functions.
  * In order to have the `wp.i18n.plural` function loaded, we have two
 choices: either the developer adds the dependence manually, or
 `wp_localize_script` goes through its values and searches for special cues
 that a return value is the special  plural structure, returned by
 `_n_js()`. This is what my patch does anyway, so we either significantly
 worse the developer experience, or face similar implementation complexity
 as the patch above.
 * We can avoid supporting “inline” scripts/styles by hacking the JS we
 need as direct `add_data()` calls.
 * We can avoid supporting specifying dependencies by just adding them
 manually after the `add_data()` calls.

 Summary: the trade-off here are between the experience of the developer
 using the code and some extra complexity of the implementation.

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


More information about the wp-trac mailing list