JSON Language Packs

It’s been deemed too difficult and too flawed to be worth implementing at this point in time. That’s relative to the demand which is fairly low.

My assessment was that I’d get more complaints of it not working than if it was not there at all.

I’ve not looked again recently, but in the thread you’ve no doubt found I list all the things that make it so difficult. Not least the crazy hashed filename system and how to derive that from an authors POT which may reference a source path not a script path.

If you have any ideas how to solve these problems, I’m open to suggestions.

But that’s exactly how wp i18n make-json works. It generates the JSON files and hashes based on the file paths provided in the POT file.

If a plugin’s POT file contains invalid paths, that’s on the plugin author. I don’t think anyone expects Loco to do any more magic than wp-cli would be able to do.

But that’s exactly how wp i18n make-json works. It generates the JSON files and hashes based on the file paths provided in the POT file.

Indeed. I wrote the code that does this a while back. I never released it because the whole system seemed so pointlessly complex and flawed that I couldn’t believe it was going to go unchanged.

If a plugin’s POT file contains invalid paths, that’s on the plugin author. I don’t think anyone expects Loco to do any more magic than wp-cli would be able to do.

I might agree with you, but having answered over 2000 support requests for this plugin I can safely say that this does not reflect reality.

To go back to your original question “is it still planned?”. Yes, in so far as I would like to add it and I will look at it again when I have time. But I can’t make it a high priority as so few people have actually asked for it.

Feel free to post a link to your plugin, so when I next get the chance to look at this I can take yours as a best case example.

I might agree with you, but having answered over 2000 support requests for this plugin I can safely say that this does not reflect reality.

Fair enough. However, my limited experience has been users asking me why my plugin doesn’t work with Loco Translate, not the other way around.

But I can’t make it a high priority as so few people have actually asked for it.

Understandable. I expected to find a lot more threads about this, after 2 years since WP 5.0 was released. Though some more general “translations don’t work” threads may be related to this indirectly.

Feel free to post a link to your plugin, so when I next get the chance to look at this I can take yours as a best case example.

https://www.ads-software.com/plugins/attribute-stock-for-woocommerce/

Thanks for the link. I will have a proper look on Monday.

You are probably right about some “translations don’t work” reports being attributable to lack of JSON support. Unfortunately people don’t tend to post back here to tell me the problem once they’ve worked out what it was, so I’ll never know what proportion it accounts for.

Thanks for the feedback thus far @timwhitlock. I appreciate the prompt responses, and the effort you’ve made with this feature already.

If you don’t get a chance to follow up on Monday I won’t hold it against you ??

Update:

The current development version 2.4.7-dev has JSON integration. This will probably get released as 2.5.

I’ll document how it works. the restrictions. the caveats. But right now it just needs some thorough testing.

Side note: You should add the Text Domain annotation to your plugin, because its slug is attribute-stock-for-woocommerce but you’re using woocommerce-attribute-stock. You may find that the GlotPress community won’t translate it unless the text domain matches the slug. Either way it causes an issue for Loco Translate and may add to reported issues.

That’s great news! I’ll definitely try it out, at least to make sure it’s working with my plugin.

Thanks for the heads up on the text domain. I’m using woocommerce-attribute-stock because that’s the slug/name of the full version. I figured the text domain of the lite version wouldn’t work with GlotPress anyway since WP says this in their docs:

The text domain must match the slug of the plugin. If your plugin is a single file called my-plugin.php or it is contained in a folder called my-plugin the domain name must be my-plugin. If your plugin is hosted on www.ads-software.com it must be the slug portion of your plugin URL (www.ads-software.com/plugins/<slug>).

I’ll add it in anyway, at least so the lite version works better with Loco Translate. The full version should already work since the plugin name and domain are the same.

I figured the text domain of the lite version wouldn’t work with GlotPress anyway

Yeh I thought so too. I did just see the following comment from here though:

“Make sure to also specify the Text Domain for your translations in the header of your plugin file. Otherwise the translations will not be picked up by translate.www.ads-software.com.”

So maybe GlotPress is reading this header now. ???♂?

Also, I’ve documented the JSON support as it stands (still in development).

https://localise.biz/wordpress/plugin/manual/json

This looks really great. Nice work!

This is live in 2.5. Sooner than I’m comfortable with, but the only way to get it tested by lots of people is to release it.

If you have any issues, please start a new topic with the specifics.