Plugin Author
Tim W
(@timwhitlock)
Hi. Thanks for this.
I’ve never used Gutenberg and don’t know anything about its templating system.
I will leave this open as a feature request and do some research.
Plugin Author
Tim W
(@timwhitlock)
It doesn’t appear that the handbook has a section dedicated to i18n, unless you can point me at a reference?
Ideally I’d like to see a theme or plugin that uses templates like your example. Do you know of one?
Thank you for following up!
I also couldn’t find any documentation or explanation.
I used it in my plugin Tag Groups, hoping that the strings in Gutenberg would then show up in GlotPress. Nothing there. I also added some strings manually to the .pot file and translated and compiled them to po/mo, with no success. So maybe I need to register them somewhere, add a text domain or something like that.
Plugin Author
Tim W
(@timwhitlock)
Thanks for the link. Good to have a working example.
If Gutenberg is to become part of WordPress core then I’m certainly keen to support it, however it looks like the template parsing is all done with a highly complex Node JS environment. I’m assuming that’s how you compile your template files into the block.build.js runtime. Is that right?
I was hoping the Gutenberg distribution would contain a parser written in PHP that I could use to extract strings from the sources, but after about an hour poking around, this doesn’t seem to be the case. Are you able to confirm that’s true? This would explain why GlotPress doesn’t support Gutenberg .js templates [yet].
Looking at the Gutenberg plugin’s own translations, it seems they’re built into a POT file via Node, then into a PHP source file that GlotPress can pick up. Presumably, if you’re building templates for your distribution then you could build a POT the same way.
Yes, it’s compiled with Webpack running on Node JS. If you want to play with a boilerplate you can try this one.
The strings could probably be extracted during that compilation process. I’m still relatively new to Gutenberg so I’m afraid I’m not of much help here. But I will be happy to share if I come across any hint how to go about it.
I assume that the Gutenberg team will sooner or later develop a workflow that is practical enough so that all plugin and theme developers know what to do.
Plugin Author
Tim W
(@timwhitlock)
Thanks for the link.
I must say I’m a bit dismayed that the fickle world of .js frameworks and “npm install magic” has made its way so deep into WordPress.
I will (when I can) look into writing a PHP implementation for parsing the .js source templates. I’ve written JS tokenizers and parsers before, but glancing at the examples this looks like a js dialect I’m not familiar with (noting the embedded HTML). Is this a standard dialect or something custom for Gutenberg?
I assume that the Gutenberg team will sooner or later develop a workflow that is practical enough so that all plugin and theme developers know what to do.
yes, this. 🙂
PS: One more link regarding the Gutenberg plugin’s own pot file: https://github.com/WordPress/gutenberg/tree/master/languages So they seem to generate that file while building. You might find this script (Webpack plugin?) somewhere there on Github among the files that are not distributed.
Plugin Author
Tim W
(@timwhitlock)
Yes, that’s the process I was referring to. I won’t be able to use that within my plugin as it has to work for every WordPress user and only use what’s shipped in the core.
I totally understand. While I’m willing to invest some time to learn all those things, I spend much time just searching for information and reverse-engineering. I trust that the documentation will catch up once the development is getting ready for the release.
Maybe your plugin could just make the assumption that all strings wrapped in __( ) are translatable. For my part it doesn’t help very much since even if I add the strings manually to the pot/po/mo their translations simply don’t show up.
Plugin Author
Tim W
(@timwhitlock)
Maybe your plugin could just make the assumption that all strings wrapped in __( ) are translatable.
I think that would be a reasonable assumption. In fact supporting all the standard i18n function patterns is a reasonable limitation (standards) and already applies to the PHP code extractor.
The real issue is that once your template is compiled into vanilla JS. those function calls are renamed/obfuscated. I actually have a JS extractor that I use locally to build this file, but I don’t think it will work running it on the “dist” code. The extraction really must be done on the source. It’s doable, but there’s no quick fix.
Plugin Author
Tim W
(@timwhitlock)
For my part it doesn’t help very much since even if I add the strings manually to the pot/po/mo their translations simply don’t show up.
This part I can’t explain, but I’ll have a play around with your plugin and see if I can see what’s wrong/missing. It’ll help me get my head into the way it all works.
OK, thanks, I will continue experimenting. Regarding the obfuscated/built code, your plugin could check if the source is available. In my plugins I distribute it in the “src” folder, and I think that making the original source available is even a condition of the license if you offer any code on wordpress.org.
Is this a standard dialect or something custom for Gutenberg?
Sorry, totally missed your question. You probably mean JSX.
Plugin Author
Tim W
(@timwhitlock)
Thanks.
Regarding your own translations.. it seems you have to do something like this:
wp_add_inline_script(
'wp-i18n',
'wp.i18n.setLocaleData('.json_encode(gutenberg_get_jed_locale_data('tag-groups')).');'
);
It works for me if I add this in your chatty_mango_tag_groups_editor_assets function. However, I’m not sure if using the same wp-i18n identifier will overwrite other scripts. (Changing the identifier stops it working). I’ll leave that with you to play with.
Thank you very much, that’s very helpful!
