[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