WordPress.org

Making WordPress.org

Opened 12 months ago

Closed 8 months ago

#3875 closed enhancement (fixed)

JavaScript Language Files

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

Description (last modified by DrewAPicture)

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 (12)

#1 @herregroen
12 months ago

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

#2 @herregroen
12 months ago

Version 0, edited 12 months ago by herregroen (next)

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


12 months ago

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


12 months ago

#5 @herregroen
12 months ago

  • Description modified (diff)
  • Summary changed from Javascript Language Packs to Javascript Language Files

#6 follow-up: @ocean90
12 months ago

wordpress.org would need to also parse JS files when generating POT files.

Any clue how this would be possible with core? The build version, which is currently used for the POT files, has only minified files: https://build.trac.wordpress.org/browser/branches/5.0/wp-includes/js/dist/

#7 in reply to: ↑ 6 @herregroen
12 months ago

Replying to ocean90:

wordpress.org would need to also parse JS files when generating POT files.

Any clue how this would be possible with core? The build version, which is currently used for the POT files, has only minified files: https://build.trac.wordpress.org/browser/branches/5.0/wp-includes/js/dist/

I've just added a patch to wp i18n to allow it to generate translations from the minified files: https://github.com/wp-cli/i18n-command/pull/85.

The only downside to this is that the minified files do not include translator's comments.

We have two options for that:

  • Configure WebPack to preserve translator's comments.
  • Also scan Gutenberg separately to pick up translator's comments.

#8 follow-up: @ocean90
12 months ago

As of today we also have the unminified dist files in https://build.trac.wordpress.org/browser/branches/5.0/wp-includes/js/dist/. Does this help us?

#9 @DrewAPicture
12 months ago

  • Description modified (diff)
  • Summary changed from Javascript Language Files to JavaScript Language Files

#10 in reply to: ↑ 8 @herregroen
12 months ago

Replying to ocean90:

As of today we also have the unminified dist files in https://build.trac.wordpress.org/browser/branches/5.0/wp-includes/js/dist/. Does this help us?

Definitely, that completely resolves the issue regarding translator's comments as they should be present in the unminified files.

It does bring up one interesting question about whether or not we should scan and generate separate files for both minified and unminified files.

I'd say both should be scanned so we always know all translations present. But only a single translation file should be created that's used for both.

This ticket was mentioned in Slack in #cli by ocean90. View the logs.


12 months ago

#12 @ocean90
8 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.