I did some quick testing with converting a regular block to a hybrid block and I’m having translation issues with it.
For what it’s worth, it seems to be working fine with TranslatePress, at least in my very limited initial testing.
When you check the code, you’ll see that the blockname.js file in a hybrid block is nearly identical to the static block aside from the save function, and the PHP file is the same as you would get with a dynamic block. What that seems to mean is that the hybrid block should work or not work the same as Pinegrow’s traditional static and dynamic blocks. Maybe there is something funny happening with your translation plugin where it is trying to do something unexpected?
As I mentioned, I’ve only done limited testing, and only with TranslatePress, so I have no idea how Polylang or WPML might behave with it.
1 Like
Yup, and that code is faulty 
TranslatePress functions very differently from WPML or Polylang.
From some more testing it is more then likely related to their PHP from the previous topic. They just are not including everything WP or plugins like WPML or Polylang require in their PHP blocks.
*edit: If Matjaz said he would fix it I trust him. Just please specify it in the next release notes and I can some additional testing for you. But IF NOT, please specify that also.
1 Like
We do not necessarily have all the plugins (and in this case, not those that absolutely require a commercial license to be tested) but we do make sure to follow the development guidelines of WordPress, which in most cases, provides excellent compatibility.
It is not excluded that special cases may occur, sometimes due to bugs, sometimes due to specifics that escape us, and we examine each feedback on a case by case basis as long as we get enough details about the issues.
Note: from what I see here: Fixing WordPress block translations - #5 by madjedo
some modifications are in the pipeline for a future update.
It also looks like some additional work needs to be done to make custom blocks support the WPML plugin.
The Custom Blocks of our site is not getting translated - WPML
Yup that’s pretty much what I reverted to doing. Still odd however that sometimes the blocks would translate flawlessly, and some types not. I mentioned one example in previous topic where I’m sure some conflict of some kind going on.
@Emmanuel If you reach out to WPML they are always happy to assist plugin developers to help ensure compatibility.
As I mentioned, we mainly focus on following WordPress coding guidelines.
Custom tweaks for specific plugins are another story but as @matjaz said, it’s in the pipeline.
1 Like
FWIW, here is a test of a hybrid block with Weglot.
I’m using LocalWP, so Weglot’s web-based visual editor doesn’t work, but that’s a different story.
Yes WPML…
20 characters
Oh my! I’ve just relaunched a Website from Oxygen to Pinegrow Blocks (not only but mainly) for getting a translatable Website. Now this. @Emmanuel is there an ETA when this is fixed? My client will kill me if it’s not working.
This are the 33 blocks in that project btw - a lot…
It depends what type of blocks. Hybrid wont work at all unless you manually register in WPML with xpath.
I think all regular javascript blocks should work.
Dynamic PHP is a hit or miss? Again manually registrering can solve most of your issues, its a hassle but it is what it is. Look at the link adam provided.
If you dont use any content management features from WP you can translate all of it with a generated .po file.
@matjaz Would it be possible for Pinegrow to export an wpml-config.xml file automatically to the theme/plugin folder, so that Hybrid blocks are compatible with WPML?
For now i have to add something like this manually:
<wpml-config>
<gutenberg-blocks>
<gutenberg-block type="mbp/mbp-sidebar-box" translate="1">
<key name="title" />
</gutenberg-block>
<gutenberg-block type="mbp/split-headline" translate="1">
<key name="split1" />
<key name="split2" />
</gutenberg-block>
</gutenberg-blocks>
</wpml-config>