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

[WordPress Trac]

#22229: Plurals in JavaScript
-------------------------+-------------------------
 Reporter:  nacin        |       Owner:  nbachiyski
     Type:  enhancement  |      Status:  accepted
 Priority:  normal       |   Milestone:  3.5
Component:  I18N         |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+-------------------------

Comment (by nbachiyski):

 On our way back from the Summit we sat together with duck_ and thought a
 bit about that and wrote some of the code in planes and airports.

 Architecture

 We have a couple of pieces:

  * Factory JS function. {{{wp.i18n.make_plural(translations, domain)}}}.
 Returns a function, which accepts a number and returns the proper plural
 form. It needs the domain, because different domains, even using the same
 language, can be using different plural rules for some weird reason. Also,
 this easily allows us to have untranslated domains without introducing a
 special factory function for English.
  * Around the factory we need two structures for plural information
 (number of plurals and the ternary operator logic). These are
 {{{wp.i18n.domains_plural_info}}} and {{{wp.i18n.english_plural_info}}}.
 We need the latter, so that we can handle untranslated strings within a
 domain.
  * We need a way to output the {{{make_plural()}}} calls in the
 localization object for a script. Here it gets tricky.
   - First, we would like to hide it in a function, because the Nacin's
 l10n_print_after hack is very error-prone, because it's long and not
 obvious, makes it hard to add more than one plural, and includes the
 object's name, which we will for sure forget to update when we rename the
 object. Let's call this function {{{_n_js()}}}. I added it to
 {{{makepot.php}}}.
   - Then, we need to assign the literal JavaScript, not a string to the
 key in the localization object. This proved hard, because we run
 {{{json_encode()}}} on the whole localization object and we don't have a
 way to tell it not to encode some values.
   - Enter {{{WP_JS_Literal}}}. This is a small class (+ a convenience
 function), which represents a literal JS value, which shouldn't be
 encoded. The easiest way to use it is to do:
 {{{
 wp_localize_script( 'handle', array( 'name' => 'string', 'code' =>
 wp_js_make_literal( 'f()' ) ), 'l10n' )
 l10n = {
         name: 'string',
         code: f()
 }
 }}}
  * The next step is how to output the {{{make_plural}}} definition only
 once, without many hacks. Since the JS literal is essentially code, w can
 allow it to have a dependancy. Then, when used in localizing a script, we
 just add this dependancy to its parent script.
  * But we don't want another JS file, just for a couple lines of code, we
 want it inline. So, with a small change to the logic of printing scripts,
 we can make scripts with source of {{{inline}}} to only add its {{{data}}}
 and not try to load its {{{src}}}.

 You can find tests in [UT1115] and [UT1116].

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22229#comment:11>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software