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)
chunk_name: [ ] where the array is an array of i18n strings in that file.That way you鈥檙e 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()
So just an update, I think I've got a webpack plugin built that will do the extractions. I'm just testing it now to see how it works. If it works well then I may just do POC in a pull request here and it can be iterated on likely.
@nerrad Can we close this?
Oh definitely, I already closed the related pull.
Most helpful comment
So just an update, I think I've got a webpack plugin built that will do the extractions. I'm just testing it now to see how it works. If it works well then I may just do POC in a pull request here and it can be iterated on likely.