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

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

 > 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.

 > 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.

 > 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.

 > 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`.

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