noreply at wordpress.org
Mon Oct 22 12:49:08 UTC 2018
Reporter: herregroen | Owner: (none)
Type: enhancement | Status: new
Priority: high | Milestone: 5.0
Component: I18N | Version: trunk
Severity: critical | Resolution:
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-
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:
Ticket URL: <https://core.trac.wordpress.org/ticket/45103#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac