Issue Overview

The wp.i18n package has made some great progress towards easier i18n in js. However, as far as I know one downside still encountered is that regardless of what js is actually loaded for a given view, all translated strings for a given locale/domain will get queued up on wp.i18n.setLocale. This isn't too much of an issue when the number of strings is relatively small. But rapidly becomes an issue if on every page load using js, the entire locale data is enqueued for that page load.

So I'd like to surface an idea of only enqueuing i18n strings that are specific to the js being used in a given view (see https://wordpress.slack.com/archives/C5UNMSU4R/p1522940224000403 where this was initially surfaced and some convo between me and @aduth about it)

1. have a webpack plugin that builds a json map of chunk_name: [ ] where the array is an array of i18n strings in that file.
2. add a php helper that uses this map to pull strings from the locale data and enqueue with the registered js bundle. (edited)

That way you’re only getting strings loaded on a view that are used in that view.

PHP side, it could be something as simple as:

//signature is something like wp_register_script_i18n($script_handle, $chunk_name_in_i81n_chunk_map, $domain)
wp_register_script_i18n( 'wp-edit-post', 'edit-post', $domain );

This might register the chunk with a new i18n property on WP_Scripts? Then when scripts are enqueued there could be the retrieval of the registered strings, grab the locale data for those strings, then merge into the final object used for the wp.i18n.setLocaleData()

Related

• i18n: Use wp-components script handle to pass locale data to wp.i18n #5910
• https://core.trac.wordpress.org/ticket/20491

Todos

• Build Webpack plugin
• Do POC php side (likely will have to be done without direct integration with WP_Scripts for now)
• Discuss solution tweaks/integration with WP core?
• Tests
• Documentation