Hey guys, I am using a component in a gravity forms formular. Now this form should be translated with WPML. In previous version it was not a big deal to translate a global block but do I see it right, that there is right now no way to translate a component? 
It does not use the post table so it probably can’t be translated the same way you were doing Global Blocks. I’m not sure why that was the decision made for Components, but it definitely goes against the grain of standard WordPress plugins. You can reach out to WPML and see if they are interested in adding Component translation to their integration. We plan on making some changes to how translation happens after we start moving from shortcodes to HTML in Pro 6.6. We plan on releasing more info on this next week and would love to get your thoughts on this announcement when we do release it. Have a great day.
Sorry, @charlie, for clarification: You say its a WPML problem?
I can set “Components (cs_global_block)” in the WPML settings to translatable but the translated version wont appear on the frontend. And this is something WPML has to deliver?
Going to HTML in 6.6 will also help with seo plugins too right? 
looking forward to that 
Unless I’m mistaken, auto-translate doesn’t exists for global blocks which was more of what I was referring too. That would be something WPML would have to take a look at. When I translated a global block through Cornerstone it worked just fine.
Individual Components aren’t a post type which is the real issue here. “cs_global_block” only refers to the image above. Storing individual components as a post type would probably solve that and it’s worth doing as it would be a standard WordPress way of doing things. HTML storage would do the same as well as it means translation plugins can look at our content and not our shortcodes. We’ll release more thoughts on this next week.
Yes it fixes a number of SEO plugin, if not all of them. As well as a number of other plugins like Jetpack and searching by post content.