[wp-meta] [Making WordPress.org] #3875: JavaScript Language Files (was: Javascript Language Files)

[Making WordPress.org]

#3875: JavaScript Language Files
--------------------------------------+-------------------------
 Reporter:  herregroen                |       Owner:  herregroen
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:
Component:  Translate Site & Plugins  |  Resolution:
 Keywords:                            |
--------------------------------------+-------------------------
Description changed by DrewAPicture:

Old description:

> 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
> [[https://github.com/WordPress/gutenberg/tree/master/packages/babel-
> plugin-makepot|@wordpress/babel-plugin-makepot]] but this would likely
> require more effect to setup on wordpress.org.
> **Action required: resolve #3748.**
> 2. 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.**
> 3. 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.**
> 4. 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.

New description:

 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
 [[https://github.com/WordPress/gutenberg/tree/master/packages/babel-
 plugin-makepot|@wordpress/babel-plugin-makepot]] but this would likely
 require more effect to setup on wordpress.org.
 **Action required: resolve #3748.**
 2. 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.**
 3. 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.**
 4. 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.

--

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/3875#comment:9>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org