[wp-trac] [WordPress Trac] #45103: Automatically load JavaScript translations when scripts are enqueued if these exist.

[WordPress Trac]

#45103: Automatically load JavaScript translations when scripts are enqueued if
these exist.
-------------------------+-------------------------
 Reporter:  herregroen   |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  high         |   Milestone:  5.0
Component:  I18N         |     Version:  trunk
 Severity:  critical     |  Resolution:
 Keywords:  needs-patch  |     Focuses:  javascript
-------------------------+-------------------------

Comment (by swissspidy):

 > Agree with the upsides to this approach and it might be the correct one,
 it should be noted however that this means that this means the
 translations file names will be calculated and all translations loaded
 into memory for every script that has translations as the inline script
 will always be set and stored regardless of whether that script is
 enqueued or not.
 >
 > This effectively means that setting translations isn't like registering
 a script but more like enqueueing a script as it will actually perform all
 calculations even if those aren't output.
 >
 > As long as this is documented and explained there should be no issue. We
 might even want to consider adding a `doing_it_wrong()` when setting
 translations on a script that's only been registered and not enqueued.

 You're right, this changes semantics. Documentation + `doing_it_wrong()`
 might be enough, though there could be cases where one enqueues a script,
 translations are loaded, and later on the script is dequeued again. I
 guess we should do some testing to see whether this an issue worth
 addressing or not.

 In the more modern PHP world I'd probably solve this by passing a closure
 (or proxy object like in #41305) to `WP_Scripts::add_inline_script()`
 instead of a string. So kinda like a mix between the first two patches.

 > Since `wp.i18n` already wraps Jed from what I've been able to find it
 actually accepts the simple key-value JSON and will internally change this
 to the Jed-style. Passing Jed-style objects would cause the `locale_data`
 itself to become a Jed-style object.
 >
 > That said it does seem to expect an empty key that contains the
 configuration settings, I'm actually not sure if this is included in the
 simple key-value JSON format or if it's something we should add.

 We need to use Jed-style files so that we automatically have the proper
 plural forms information and things like that.

 Here's an example file: https://github.com/GlotPress/GlotPress-
 WP/blob/0de4570063cba85049bdce214ae7e7ff93a2193e/tests/phpunit/data
 /translation-jed1x.json

 We can get the `locale_data` object in PHP, maybe override the domain if
 necessary  and then pass this object to `wp.i18n.setLocaleData()`.

 > I'd say the following should be tried:

 Sounds good!

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