r4nd99y

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.

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 .jsons 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 .jsons, or maybe Loco should allow to translate .jsons 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?

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!

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 6 years, 2 months ago by r4nd99y.

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?

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 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 tool, any idea if that is just an outdated hack meant for plugins in www.ads-software.com repo or should all plugins include the strings in PHP form as well?