Hi,
I saw @charlie mentioning on the regular form that 6.5.0 will be compatible with WPML again, by using __ within components, which would be great. But the changelog doesn’t mention this. Before I’m going to beta-test WPML compatibility, I just wanted to know if this is at all something that 6.5.0 should be improving? If so, I will defiantly start testing some of my websites!
Absolutely. So if you enable Twig and keep the WordPress extension enabled you’ll have access to that via Twig. See the docs for more info. I would probably limit this to just Component since most of WPML should already work with our other elements or if you’d rather handle translations through their String Translation plugin. Have a great day.
{# Translate a string through the WordPress function __ #}
{{ __('My Content', 'my_localize_domain') }}
Hi @charlie,
thanks for getting responding so quickly!
I’ll by testing WPML’s automatic translation option, which is becoming the new default. On the latest stable version of Pro, that does not work at all, and the theme.co docs state that ‘components are not translatable’ .
But if I understand you correctly, that changes fundamentally with 6.5.0 and enabling Twig. If that’s correct, i’m going to test that on a staging environment. And if I find any bugs, i’ll report them on the beta-forum. Or confirm that everything is working as expected 
Am I drawing the right conclusions here?
You still need to use the Twig Dynamic Content I posted earlier when Twig is enabled in a Component. It’ll allow you to translate through their String Translation system I believe. If you reuse the same content you should only need to translate it once though. I’m not sure if using that will have the component show up in the automatic translations system, but it might.
Hi Charlie,
just for my understanding: that means i don’t have to create new layouts/pages per language anymore? If i now press translate automatically in wpml i don’t have to care about the rest anymore?
How is it with existing pages? With a page that i have translated into 5 languages, there is different content and products per language. If i don’t use automatic translation here, does everything stay the same?
Thank you very much for your answer
All I’m really saying is that you can tap into the default WordPress translation system via this dynamic content if that isn’t clear.
I reached out to WPML about this feature, but never got a response as what this means to them so I’m kind of spitballing here. At the very least other plugins can translate our content easily. I don’t think this function (__) is part of their automatic translations, but I could be wrong. I’m pretty sure this is used by their String Translator plugin.
I’m pretty sure you would still need another page translation setup for the language switcher to show up. If you don’t use automatic translation nothing will change.
Hope this helps, have a great weekend.
Hi @charlie,
I’m not 100% sure, but I do believe that WPML’s automatic translation function is technically handeling translations in the same way as when using the string translation, and indeed tapping into the __-function.
The issue with the current stable release of Pro, is that translations made through WPML String Translations don’t show up on the frontend, but do show up in the Pro-editor. That’s unfortunate, as it means all translation edits need to be confirmed again by opening the translated page in Pro, use the language switcher, and save the page again.
If we correctly assume that the automatic translation works the same as string translation, then it’s seriously broken in beta3.
I’ve made an exact copy of the website to a staging environment.
When using automatic translation on the stable version of Pro, after enabling automatic translation, the user is offered the option to review the automatic translation:
But in beta3, when clicking the ‘view’ button, you are not redirected to that review-page. Instead, the translated page itself reloads. And that’s it.
I’ve reached out to WPML support as well, using the stable version of Pro as an example. The first line support concluded that it looked like the elements weren’t translatable, but they escalated the issue to the second line support. I expect them to come to the same conclusion, as __ was missing in the elements previously. I actually expected that with the addition of __ in all elements, translation through WPML would work again. But now there’s the weird issue where reviewing the translations is reloading the page, instead of showing the correct page. I have not (yet) found out why that’s happening.
If you’d like to have access to this staging environment as well and test the WPML integration yourself, I would be happy to share the credentials. I could even add some automatic translation credits I bought, so you test the whole process yourself. Costs me a few bugs, but that’s worth having Pro and WPML integration running again.
.
Hi @charlie,
i’ve spend some more time on testing WPML with beta3 and it looks like there’s something going on with Global Blocks as well. They can’t be translated through WPML for a while. WPML states on this page they reached out but more user feedback is need.
My Feedback: i’m forced now to use Pro’s Language-switcher sometimes, but I would really like to use the default WPML string-editor, so that there’s only one single layout in Pro, and edits to the original language will automatically be reflected on the translated pages; only the texts differ. But I think you got that already 
Back to Global Blocks: could it be that there’s still an issue with elements, which now have __, that prevents this to work for elements that are part of a Global Block?
Final thought after some time testing: managing multi-language websites that use Pro/Concerstone, has always been quite a struggle. The introduction of the language flags in the editor provided some relief, but had its own disadvantages, such as loss of design-synchronization. Now translation plugins like WPML move towards automatic translation, it becomes even more interesting to fully rely on them, instead of manually using different pages per language in Pro. I would like to share my opinion that now would be the right time to remove the language switcher in Pro completely, and make sure the theme is fully meeting the standards needed to let plugins like WPML take full control of translating the entire website. With all developments of the last year, I personally think that’s something you and the team definitely could achieve! And Ik would be more then happy to assist by testing, or even diving into codebases.
I’m curious what your thoughts are on supporting multi-languagal websites from the theme, in the foreseeable further. And off course on the issue mentioned: Global Blocks are not available to WPML, despite te introduction of __.
Hi,
does the string translation works on 6.4.20 too (pages/loopers)?
Yes it would be great if that now works like it should and we can use automatic translation when we need it!
BUT pls do not disable/remove the language flag => let the user decide (switch or something in settings) how translation should work!
I have some sites, where i have different content for different languages, so removing the language switch will completly destroy those websites…
thanks
@dhunink Are you adding in __ through Dynamic Content like I showed earlier? You keep referring to that function as if it is everywhere, we have not changed our elements to use that everywhere. We have just given you the ability to use that function with Twig, which is based on how Timber handles this. WPML has never supported Global Blocks, the main appeal of this feature was to add a potential workaround for Components and Global Blocks.
{# This is Dynamic Content in something like a Text Element #}
{{ __('My Content', 'my_localize_domain') }}
How WPML works internally with Cornerstone is that it uses our Cornerstone internal element JSON to translate the page. I’m guessing they wouldn’t know what to do when you are adding in that Dynamic Content which is why I bring up their String Translator, which would be separate from the translation system they use for Cornerstone.
I agree with removing the language switcher inside Cornerstone. I hardly ever see anyone creating different designs based on language. And even if they were that could be easily handled with a condition on a Single Layout or Archive Layout which could check the language. I do think being able to manually translate in Cornerstone is an interesting idea, however this being limited to content / data and not design could be better overall. Especially since this language switcher only works with WPML and not any site that could be translating. I’d love to take a user poll on this exact thing and get a better idea on the future of internalization in Cornerstone.
@deranaloge If you used the Dynamic Content I referenced earlier you could always pass in a looper value into the WP translation system.
{{ __(looper.item.someKey) }}
Nothing changed with the WPML integration. I probably misspoke on how the language flag works to what I know about it, so you don’t have to worry there.
Let me know if you have any additional thoughts or questions.
Hi @charlie,
thanks for getting back to me! I think we indeed misunderstood each other. I thought you were saying that the default internationalization function __ has been introduced everywhere, and that this would finally solve all the troubles i’ve had with using WPML en Pro together, since the start. That was also a misinterpretation from my part, as I thought WPML would use that function to detect translatable content, but as you clarify, they use the API instead.
For now I think I think we have three things at hand. First, the current, unchanged, integration with WPML that works in the stable version, doesn’t work in the latest beta anymore. See my post with screenshots. That’s a bug, I guess.
Secondly: WPML and Pro still don’t play along all that well, especially with their automatic translation. But perhaps it’s better to open a topic about that on the regular support forum, when I have another case at hand?
Last, there’s your suggestion to enable Twig and being able to translate Dynamic Content as well, if I get it right. If i’m right, I’ll spend some more time on testing that as well, with a different perspective.
Looking forward to your response!
I’d reach out to WPML on the first one and second one. The WPML integration is unchanged and they handle the element translations on their end. If this is a global block / component the translation for that never existed. You can send me a site to look if you’d like.
Definitely try out the new Twig Dynamic Content. I’d probably leave the translation part for Global Blocks / Components since their translation system should work for regular pages, posts, and layouts. They sent me a message yesterday they’re going to checkout this Twig integration so we’ll see what this adds to translations in the future.
Have a great weekend.
Hi @charlie,
I think we weren’t on the same page before: i’ve had a lot of issues with WPML when using Pro for the past few years, and thought you where saying the WPML integration has improved in stability and reducing issues. So I responded and tested on that premises, but that’s not what you meant.
I have enabled Twig now, and I totally get the point you’re trying to make. It’s an impressive system to expand the default DC and make so much more possible, including translating things that weren’t translatable by WPML before. But i’ve got so much more ideas floating around instantly
That being said, I think it’s worth checking the screenshots and issues described in WPML in 6.5.0. That’s without Twig enabled, but that shouldn’t matter for the particular issue.
Great to hear you’re in contact with WPML! I think it makes sense to leave the Global Blocks/translation for now, but noted it as a feature request. For now I think it’s more importend to ensure that the WPML integration keeps working, as it seems to be broken in the beta3, when reviewing automatic translations.
I’ve had other issues in the past few weeks, and I keep sending them to WPML’s support. It’s becoming a bit of a blame-game, as they don’t seem to understand how Pro works. Perhaps I’ll open a topic in regular support as well, but for now I think it’s WPML that needs to adapt to the way Pro works, since that’s quite standard, and WPML is not. But if you want, I can share some live-examples of two WPML sites that run on the current stable version, and keep having issues?
Having said all that, I now fully understand your enthusiasm over Twig. It’s very very very promising!
I would send me a site to look at. I think I might’ve spoken too soon as the message from WPML as I think they were just testing their integration that was already in place, but I’ll make sure they eventually get some eyes on the Twig aspect. What you see in that screenshot probably exists in 6.4 as nothing on the WPML end has changed. WPML’s Pro integration is pretty unique so not many on their team know how it works. Glad you share the enthusiasm for Twig and I’m sure it’ll serve you well in the future.