Title: wp_set_script_translations
Last modified: December 20, 2018

---

# wp_set_script_translations

 *  Resolved [r4nd99y](https://wordpress.org/support/users/r4nd99y/)
 * (@r4nd99y)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/wp_set_script_translations/)
 * Hello,
 * does this plugin work with the new `wp_set_script_translations()` function? For
   example, with the [https://wordpress.org/plugins/woo-gutenberg-products-block/](https://wordpress.org/plugins/woo-gutenberg-products-block/)
   plugin. It doesn’t have a pot, so I created it with Loco, translated the string“
   Choose which products you’d like to display:” which the products block uses. 
   But the string does not seem to be loaded.
 * Thanks!

Viewing 15 replies - 1 through 15 (of 15 total)

 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11011692)
 * Loco Translate doesn’t yet generate the .json translation files required for 
   this.
 * This is something I’m looking into, but as WP5 is so new I’ve been waiting see
   real world examples. I’ll take a look at your plugin ASAP.
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11018034)
 * Update: I’ve spent the day looking at this, and it’s not looking good.
 * Generating JSON translation files is something I can add to Loco Translate quite
   easily, but ensuring they’re named correctly and loading them from alternative
   locations is made extremely difficult by the new system.
 * I’ll continue looking into this, but for the time-being I’m watching what happens
   with this feature as it’s very new.
 * I note that the plugin you mention doesn’t actually include JSON translation 
   files when you install its language pack. (I tried Spanish). I also note that
   the translatable JS strings in WordPress Core (despite being split into 11 separate
   JSON files) are also loaded by some fallback method directly from the MO file.
 * These two things lead me to thinking that it’s still early days for this feature.
   Perhaps GlotPress is still developing its tools, or perhaps translators need 
   to catch up. I really have no idea.
 * If you want to get your strings working directly from the MO file then perhaps
   contact WooCommerce support and ask them about it.
 * I’m shelving the issue until at least the New Year.
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11065440)
 * Update: The latest development version has experimental support for generating
   JSON files in the new WordPress format.
 * However, Loco Translate’s [LoadHelper](https://github.com/loco/wp-loco/blob/master/src/hooks/LoadHelper.php)
   does not _yet_ allow the JSON files to be loaded from non-standard locations.
   This is because WordPress is pending some bugfixes to the load_script_textdomain
   procedure and I’m waiting to see what happens. The filters are not currently 
   very useful, compared with the load_theme_textdomain and load_plugin_textdomain
   equivalents.
 * What does work is this –
 * When you save a PO file from the Loco Translate editor, any strings with file
   references that point correctly to a JavaScript file will be pulled out and saved
   into a JED formatted JSON file with the correct name for the reference.
 * This means two things need to be in place:
 * (1) the strings must be extracted with a .js file reference. Loco Translate’s
   string extractor works on .js files when enabled in settings, plus it supports
   the /* references: */ annotation in .php files.
 * (2) The referenced file must exist and be relative to the bundle root.
 *  Thread Starter [r4nd99y](https://wordpress.org/support/users/r4nd99y/)
 * (@r4nd99y)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11095764)
 * Thanks for the updates. Hope this gets resolved soon.
 * From a plugin developing point of view, is it correct to provide a `pot` generated
   with [babel-plugin-makepot](https://github.com/WordPress/gutenberg/tree/master/packages/babel-plugin-makepot)
   and just calling `wp_set_script_translations( 'my-handle', 'my-domain' );` should
   make it translatable with Loco in the future?
 * There is also [pot-to-php](https://github.com/WordPress/gutenberg/blob/master/packages/i18n/tools/pot-to-php.js)
   tool, any idea if that is just an outdated hack meant for plugins in WordPress.
   org repo or should all plugins include the strings in PHP form as well?
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11095813)
 * Loco Translate doesn’t care what generated the POT file as long as the requirements
   I mentioned above are in place.
 * It also doesn’t care (or even know) if you called wp_set_script_translations.
   This is not what it uses to generate JSON files. It uses only the file references
   as mentioned.
 * I can’t comment on the suitability of third party tools, but I expect most good
   tools will generate the correct file references.
 * Do you have good reason to use an additional tool to generate POT files? If Loco
   Translate’s .js extractor isn’t fit for purpose, I need to know.
 * If you’re in any doubt about any of Loco Translate’s capabilities here, please
   try the development version. Feed back so far has been _zero_ which makes it 
   much slower to get anything live.
 *  Thread Starter [r4nd99y](https://wordpress.org/support/users/r4nd99y/)
 * (@r4nd99y)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11096091)
 * > Do you have good reason to use an additional tool to generate POT files?
 * I generate the pot from development files and ship minified files, where `__()`
   is renamed to something else and I don’t expect strings to be extracted from 
   there. So while the reference in the pot may be `#: src/blocks/grid/row.js:32`
   the file loaded on Gutenberg page is `dist/row.js`. I suppose this is why the
   development version of Loco Translate is giving me these warnings: `Warning: 
   src/blocks/grid/row.js not found in bundle`.
 * I tested with the `woo-gutenberg-products-block` plugin. Did “Create template”,
   edited a string, it shows up in the `wp-content/languages/loco/plugins/woo-gutenberg-
   products-block-en_US.po`:
 *     ```
       #: assets/js/product-category-block.js:158
       msgid "Showing product block preview."
       msgstr "Test123"
       ```
   
 * It also generated 6 `.json` files, none of which include the string `Test123`.
 * On the Gutenberg page the string is also not translated, so (not) working as 
   expected?
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11096175)
 * Compressing files into a production bundle with a different path isn’t going 
   to work under this new system. I don’t know why WordPress went down the route
   of binding specific strings to specific .js files. I think it’s a terrible idea
   and all it achieves is slightly smaller JSON files.
 * However, this is the way it is. Loco Translate has to (1) anticipate the name
   of the JSON file that WordPress wants AND (2) know which strings it should contain.
   The only way that can happen is if the .js file reference matches.
 * Minified extensions are handled by Loco Translate, but the rest of the path can’t
   change. You could have `js/blocks/grid/row.js` for extraction and `js/blocks/
   grid/row.min.js` shipped in your plugin. I could add filters to let developers
   modify these paths on the fly, but it’s just getting way too complicated.
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11096329)
 * Regarding the woo-gutenberg-products-block issue. It looks to me like the plugin
   calls `wp_set_script_translations` without registering a script to go with it.
 * Also the script `assets/js/product-category-block.js` is not actually in the 
   plugin.
 * Basically, it looks broken.
 *  Thread Starter [r4nd99y](https://wordpress.org/support/users/r4nd99y/)
 * (@r4nd99y)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11096519)
 * Looks like they also got the same thing going on, references in `languages/woo-
   gutenberg-products-block.php` point to `assets/js/..` while the actual assets
   are served from `build/`.
 * Would it help to rewrite these references to point to the minified files after
   generating the `pot`? (on my end I mean, I don’t expect Loco to do that)
    -  This reply was modified 7 years, 6 months ago by [r4nd99y](https://wordpress.org/support/users/r4nd99y/).
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11096580)
 * If you rewrite the references to point to minified files, the JSON generation
   should work, but it’ll break the “source view” feature.
 * I just [added a filter](https://github.com/loco/wp-loco/blob/528e220fc1ea849043f097dca68b6561c246aa69/src/ajax/SaveController.php#L129)
   called `loco_script_relative_path` which acts similarly to WordPress `load_script_textdomain_relative_path`
   filter. This is consulted when the JSON files are generated, so you can fix the
   references that way now.
 * On a side note, I see that WP 5.0.3 has been released that fixes some of the 
   filtering problems I mentioned. I’m going to get the custom folder loading working
   with JSONs shortly.
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 6 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11099283)
 * Related:
 * Issue with woo-gutenberg-products-block is being tracked:
    [https://github.com/woocommerce/woocommerce-gutenberg-products-block/issues/336](https://github.com/woocommerce/woocommerce-gutenberg-products-block/issues/336)
 * I commented (probably in the wrong place) about this whole reference problem:
   
   [https://meta.trac.wordpress.org/ticket/3876#comment:27](https://meta.trac.wordpress.org/ticket/3876#comment:27)
 *  Thread Starter [r4nd99y](https://wordpress.org/support/users/r4nd99y/)
 * (@r4nd99y)
 * [7 years, 3 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11370317)
 * Any update on this situation? I see that WC Gutenberg Products Blocks plugin 
   includes some `json` files now, but no way to modify any fork/modify/generate
   anything with Loco?
 * Thanks!
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 3 months ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11370367)
 * No update. This new system is a disaster for third parties.
 * I looked into generating JSON files from file references in PO files. Doable,
   but flawed. But the real problem is there’s no way to reliably load JSON files
   from an alternative location, or merge custom translations on top of installed
   ones.
 * Basically, this feature is on ice.
 *  Thread Starter [r4nd99y](https://wordpress.org/support/users/r4nd99y/)
 * (@r4nd99y)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11579285)
 * Currently working on a plugin that I need in my native language but I still want
   to make it in English to maybe reuse later.
 * I set the i18n up following [this guide](https://getwithgutenberg.com#3-Generate-the-language-files).
 * Using `wp i18n make-pot` to create `plugin/languages/plugin.pot` which includes
   php and JS strings (running it while the JS is compiled but not minifed, so the
   file references are good but `__()` calls can still be identified).
 * Then `cp plugin.pot plugin-en_US.po` to get the `.po` and `wp i18n make-json`
   to get the `.json` files with their respective hashes based on the references.
   
   Now `wp_set_script_translations()` loads these `.json`s when applicable.
 * Now to translate to another language with Loco:
 * the `.pot` is good, contains both PHP and JS strings. I create the new language
   with Loco to `wp-content/langauges/loco/plugins`, translate some strings and 
   save. Since Loco doesn’t create the `.json`‘s currently I run `wp i18n make-json./`
   in that directory to get them.
 * If I saved the language to `wp-content/languages/plugins` it would already work(
   since it seems to be looking there by default), but since they’re in `/loco` 
   I also added this filter:
 *     ```
       add_filter('load_script_translation_file', function($file, $handle, $domain) {
           if($domain === 'my-domain') {
               if(strpos($file, 'wp-content/languages/plugins') !== false) {
                   $loco_file = str_replace('wp-content/languages/plugins', 'wp-content/languages/loco/plugins', $file);
                   if(file_exists($loco_file)) {
                       return $loco_file;
                   }
               }
           }
           return $file;
       }, 10, 3);
       ```
   
 * and with that I was able to translate JS strings with Loco.
 * A little caveat being that `wp i18n make-json` strips the JS strings from the`.
   po` so next time I go to translate with Loco the JS strings are no longer available.
   So currently I back up the `.po` and restore it after running `make-json`.
 * So that’s pretty much what I’ve got right now… is that a reasonable way to handle
   it?
 * Between the `pre_load_script_translations`, `load_script_translation_file` and`
   load_script_translations` filters, is there still no workable permanent solution
   for this plugin?
 * Not sure how it’s supposed to work in the end, whether the `.po` should retain
   the JS strings after creating `.json`s, or maybe Loco should allow to translate`.
   json`s directly (probably cumbersome to find strings from different files unless
   you can pool them in the editor)?
 * Is there still a development version that handles `.json` generation?
 *  Plugin Author [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * (@timwhitlock)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11579576)
 * Thanks for posting.
 * > So that’s pretty much what I’ve got right now… is that a reasonable way to 
   > handle it?
 * Your example means the custom JSON file is loaded INSTEAD of the installed system
   file. If that works for you then I guess it’s reasonable, but it doesn’t work
   for my plugin because it’s not equivalent to the current MO file loading. (it
   doesn’t merge)
 * If you look at how Loco Translate loads translations from its custom directory,
   it does so ON TOP of existing installed translations. This is required because
   often users just want to [customize a subset of strings](https://localise.biz/wordpress/plugin/custom-translations).
   The horrendous new JSON system makes this _difficult_. I looked at merging the
   strings at JS level. I looked at merging via back end. I was’t happy with anything
   I tried.
 * > is there still no workable permanent solution for this plugin?
 * I’ve looked and re-looked at this, and every time I give up and shelve it for
   another day. So currently, no; there is no permanent solution yet. I’ve been 
   hoping that updates to WordPress 5.2 would include new filters to help with this.
   I haven’t checked recently, but my general feeling is that the new system will
   continue to be a problem for this plugin on various fronts, and not just the 
   file loading.
 * > Is there still a development version that handles .json generation?
 * No, but there is some [commented-out code](https://github.com/loco/wp-loco/blob/2.2.2/src/ajax/SaveController.php#L115)
   kicking around. You’re welcome to play around with it, but it’s terribly flawed
   for the [reasons I gave here](https://meta.trac.wordpress.org/ticket/3876#comment:27).
 * > Not sure how it’s supposed to work in the end, whether the .po should retain
   > the JS strings after creating…
 * Personally I think the PO should always contain all strings in the text domain.
   MO files could reasonably exclude JS-only strings, but it wouldn’t gain much 
   to do so, and frankly this is moot until bigger issues are resolved.

Viewing 15 replies - 1 through 15 (of 15 total)

The topic ‘wp_set_script_translations’ is closed to new replies.

 * ![](https://ps.w.org/loco-translate/assets/icon-256x256.png?rev=1000676)
 * [Loco Translate](https://wordpress.org/plugins/loco-translate/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/loco-translate/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/loco-translate/)
 * [Active Topics](https://wordpress.org/support/plugin/loco-translate/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/loco-translate/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/loco-translate/reviews/)

 * 15 replies
 * 2 participants
 * Last reply from: [Tim W](https://wordpress.org/support/users/timwhitlock/)
 * Last activity: [7 years, 1 month ago](https://wordpress.org/support/topic/wp_set_script_translations/#post-11579576)
 * Status: resolved