Background of the issue:
I am trying to translate Elementor Pages and Templates with WPML in a consistent way. The goal is that identical Elementor structures (Containers, Buttons, Images) are always recognized the same way by WPML and appear reliably in the Advanced Translation Editor (ATE).
Symptoms:
We face a systematic inconsistency when using WPML with Elementor. Identical Elementor Pages/Templates are sometimes processed differently by WPML. In some cases, Container, Button, or Image links are visible in the Advanced Translation Editor (ATE). In other cases, the same widget structure in a different Page/Template does not show those fields in ATE at all. This results in two Elementor items with identical structure producing completely different translation packages.
Questions:
Why are identical Elementor Pages/Templates treated differently by WPML?
How can I ensure consistent recognition of Elementor structures in WPML's Advanced Translation Editor?
Do you mind to access directly the website to have a look? The website is running on a the wpml account of our client. But as i wasn't able to add me as team on his account i open the ticket on mine.
As soon as you set the ticket to private i will send credential infos, post and template id that are structured identical but have a different ate output.
If you need further help with this, please share the access details to your site with me. I'm enabling a private message for the following reply.
Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please back up the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
I'm sorry if the problem is on my side. I find it hard to understand and see the issue you describe.
How do you create a copy from a page or a template?
What are the field names?
What is the difference between issues a) and b)?
What I actually need to know are the steps to replicate the problems.
And it would be awesome if you could attach some screenshots of the problems.
It would even be better if you could send me a video.
You use the free online screencast service Komodo - hidden link.
This should help me see if you do anything wrong.
Are you familiar with elementor? I am sending you some screencasts to show...
PAGE COPIES WITH INCONSISTENT ATE -->
First you see the page "Apartments" were the "Detail" buttons and its link are translatable and
in comparison the copy of it i used to build a similar page called "Suites" were the Details Buttons are not translatable...
hidden link
TEMPLATE COPIES WITH INCONSISTENT ATE -->
This is a second example regarding the Template "Apartment" were you see the ate diplays Button and Links-target and on a second template "Zimmer" were button elements can not be edit
hidden link
Important: All pages and elements that I have shown you in comparison use the same structure and the same elements.
I could give you dozens more examples and show you where the WPML cache seems to be hallucinating, randomly displaying or not displaying elements, modules, images, and meta data for translation.
I need a solution that I can reliably hand over to my client – I think the problem lies with WPML's caching or memory management and is something for your development department to look into.
We have been able to resolve the issue on our side and would like to close this ticket.
The root cause was not the XML configuration itself, but how WPML generates translation packages for Elementor:
As long as a field (e.g. a link in a button, container, or image) has never been actively saved in any language version, it will not appear in ATE. Once we opened the translation, edited and saved the link, the field immediately appeared in the original language ATE as well and became translatable.
This confirms that the behavior is related to package handling rather than configuration. With this workaround, the previously missing fields are now consistently visible and translatable.
We are therefore closing the ticket to avoid further complications.
