Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea for only loading specific i18n strings needed in a given view (wp.i18n) #6015

Closed
2 of 5 tasks
nerrad opened this issue Apr 5, 2018 · 3 comments
Closed
2 of 5 tasks
Labels
Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts Internationalization (i18n) Issues or PRs related to internationalization efforts [Type] Build Tooling Issues or PRs related to build tooling

Comments

@nerrad
Copy link
Contributor

nerrad commented Apr 5, 2018

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

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
@nerrad
Copy link
Contributor Author

nerrad commented Apr 6, 2018

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.

@pento pento added [Type] Build Tooling Issues or PRs related to build tooling Internationalization (i18n) Issues or PRs related to internationalization efforts Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts labels Apr 13, 2018
@swissspidy swissspidy changed the title Idea for only loading specific i18n strings needed in a given view (wp.i81n) Idea for only loading specific i18n strings needed in a given view (wp.i18n) Apr 13, 2018
@mcsf mcsf added the Future label Jul 18, 2018
@mtias mtias added this to the Future: 5.1 Onwards milestone Oct 12, 2018
@swissspidy
Copy link
Member

@nerrad Can we close this?

@nerrad
Copy link
Contributor Author

nerrad commented Nov 11, 2018

Oh definitely, I already closed the related pull.

@nerrad nerrad closed this as completed Nov 11, 2018
@mtias mtias modified the milestones: Future: 5.1, WordPress 5.0 RC Nov 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts Internationalization (i18n) Issues or PRs related to internationalization efforts [Type] Build Tooling Issues or PRs related to build tooling
Projects
None yet
Development

No branches or pull requests

5 participants