[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:6 nerrad]:
 > I'm wondering if we should introduce an api for scripts to indicate they
 have translation strings.  It be nice if we could put extra arguments on
 `wp_register_script` but that already has a lot of arguments and retooling
 could be painful.
 >
 > What about something like:
 >
 > {{{
 > function wp_script_has_translation( $handle, $domain ) {
 >     $wp_scripts = wp_scripts();
 >     if ( ! ( $wp_scripts instanceof WP_Scripts ) ) {
 >         _wp_scripts_maybe_doing_it_wrong( __FUNCTION__ );
 >         return false;
 >     }
 >     return $wp_scripts->has_translation( $handle, $domain );
 > }
 > }}}
 >
 > Then in `WP_Scripts` there could be tracking of what handles have been
 registered as having translation strings for when time comes to write
 `wp.i18n.setLocaleData` inline.  The beauty of this is is saves having to
 auto-detect whether js files have translations or not (which could get
 expensive) and also ensures that the translation is only loaded when the
 script itself is enqueued.  Plus it handily links the domain to the script
 so there's no guessing at what domain the script file belongs to (or
 trying to auto-detect that which could be difficult).
 >
 > So the new api bits would be the function `wp_script_has_translation`
 and the logic etc for `WP_Scripts::has_translation`

 That should work.

 From there, before a script is output in `do_item`, we can find it's
 relative path to the plugin, theme, child theme or root urls. md5 that and
 find the correct translation file in the appropriate language directory.
 The domain and locale are known so no issues there.

 This can then be output using basically `register_inline_script ` from the
 `GB_Scripts ` class. Likely as a new method on `WP_Scripts`.

 One more thing I think we should add is that in `load_plugin_textdomain`,
 `load_muplugin_textdomain`, `load_theme_textdomain` and
 `load_child_theme_textdomain` we should remember the paths passed so that,
 if the translation is for one of those registered domains we can also look
 in the directories passed there.

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