Making WordPress.org

Opened 3 years ago

Last modified 10 months ago

#3875 closed enhancement

Javascript Language Files — at Version 5

Reported by: herregroen Owned by: herregroen
Milestone: Priority: normal
Component: Translate Site & Plugins Keywords:

Description (last modified by herregroen)

Javascript is starting to become increasingly important in core, plugin and theme development. Especially in light of the upcoming 5.0 release that will include Gutenberg.

When it comes to translations present in PHP we've got a great setup, however this currently can't be leveraged for translations in JS without some workarounds ( such as generating a PHP file containing all translatable strings from JS ).

These workarounds also make it difficult to selectively load only the required translations in JavaScript.

Ideally no workarounds would be needed, developers can use wp.i18n.__ in JavaScript just as they would use __ in PHP with no additional steps required. In addition to that end users would only have to load the translations they need rather than all translations.

In order to make this happen several steps would have to be taken:

  1. wordpress.org would need to also parse JS files when generating POT files. I believe #3748 is the best way to allow this. A possible alternative here would be to use @wordpress/babel-plugin-makepot but this would likely require more effect to setup on wordpress.org.

Action required: resolve #3748.

  1. wordpress.org would need to split translations into multiple files when building language packs. The simplest way to achieve this would be to change the wporg-gp-customizations plugin to generate multiple PO and MO files. One pair for all translation entries ( possibly only those occurring only in PHP files ) and one file per JS file, each containing all translation entries that occur in that file. These files would then all be added to the ZIP as is currently already done. From there the process could continue as normal.

Action required: patch wporg-gp-customizations #3876.

  1. WordPress installations would download these updated language packs as normal. The normal language pack file will still exist and contain all the translations it always did preserving full BC. In addition to that the JS translations would be present on a file-by-file basis.

No action required.

  1. WordPress will require a patch so that when a script is enqueued a check is done to see if a translation file exists for that specific script and, if so, load those translations using wp_localize_script or something similar and ensure a small inline script is added that loads those translations into wp.i18n. This inline script should always run before the dependant JS file is loaded.

Action required: patch WordPress Core #core45103

If all these steps are made I believe we'll be in a situation where:

  • Users will have the fastest experience, loading only the translations they need.
  • Site Owners can follow the same update and installation process they're used to and have a site that's as fast as possible when it comes to translations with the downside of a possible increase in size of language packs downloaded.
  • Translators can continue to work exactly as they are, with JS translations automatically showing up in their current workflow with full access to translator's comments as source JS files will also be scanned.
  • Developers do not need any workarounds and can likewise continue with the same processes they are already employing. The only exception here would be developers not shipping source files who would need to configure their build process to preserve translator's comments.

Change History (5)

#1 @herregroen
3 years ago

Ticket for the wporg-gp-customizations: #3876.

#2 @herregroen
3 years ago

Ticket for WordPress Core: #core45103

Last edited 3 years ago by herregroen (previous) (diff)

This ticket was mentioned in Slack in #core-committers by herregroen. View the logs.

3 years ago

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.

3 years ago

#5 @herregroen
3 years ago

  • Description modified (diff)
  • Summary changed from Javascript Language Packs to Javascript Language Files
Note: See TracTickets for help on using tickets.