[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 herregroen):

 Replying to [comment:12 swissspidy]:
 > Feels like this goes into a good direction 👍
 >
 > Instead of setting the text domain on the dependency object,
 `WP_Scripts::set_translations()` could do all tasks from `WP_Scripts::
 print_inline_translations()` and then simply call
 `WP_Scripts::add_inline_script()`.
 >
 > This would reduce complexity a bit as there are no changes needed to
 `_WP_Dependency` or `WP_Scripts::do_item()`.
 >
 > Oh, and `WP_Scripts::set_translations()` needs to add `wp-i18n` to the
 handle's list of dependencies.
 >
 > I tried to do this in [attachment:"45103.2.diff"]. Please correct me if
 I'm wrong :-)

 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.

 Replying to [comment:12 swissspidy]:
 > > Will core only be handling .json files (which I'm okay with, just want
 to clarify)? If so, we should document the expected shape of the json
 object.
 >
 > Yes (IMO) and yes.

 Completely in agreement.

 Replying to [comment:12 swissspidy]:
 > > Is the shape of the json object what jed expects? I know in the work I
 did for the GB pull I had to coerce locale data into an object jed
 expected. I'm not familiar with what glotpress outputs so I just thought
 I'd raise this as a point to investigate if its not already known.
 >
 > GlotPress supports simple key-value JSON files and Jed-style JSON files
 for export. See #meta3876. I think it's possible and makes sense to
 support and use Jed-style files.
 >
 > Makes documentation and adoption easier too, as this standard has
 already been around a while.
 >
 > Should we perhaps reach out to l10n software vendors like Poedit to see
 if they would support JSON files in the future? Makes developers' lives
 easier.

 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.

 Replying to [comment:12 swissspidy]:
 > > I'm assuming the filename will be expected to be this explicit format
 (md5 hashed script name etc, and no provision for providing the name of
 the file)? If so, we'll need to document the expected filename structure.
 >
 > Definitely needs to be documented. Perhaps for plugins shipping their
 own translations we can also accept `{$domain}-{$locale}-{$handle}.json`
 style file names, instead of requiring them to suddenly use md5. On
 WordPress.org we don't know the script handles, hence the file name hash
 approach.

 Great idea!

 Replying to [comment:12 swissspidy]:
 > > This could provide plugins the option to provide their own expected
 filename for a translation file?
 >
 > If we support something like `{$domain}-{$locale}-{$handle}.json`, I
 don't think such a filter is needed.
 >
 > However, I think we should move all the filename logic to a more
 suitable place like `wp-includes/l10n.php`.

 `{$domain}-{$locale}-{$handle}.json` would be the best option I think.

 I'd say the following should be tried:
 1. If a path has been passed,
 `{$custom_path}/{$domain}-{$locale}-{$handle}.json`.
 2. If a path has been passed,
 `{$custom_path}/{$domain}-{$locale}-{$md5}.json`.
 3 Always, `{$languages_path}/{$domain}-{$locale}-{$md5}.json`.

 This would also leave the option for plugins to do provide their own
 language files but do so with their own GlotPress install.

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