Home›Support›English Support›[Resolved] ACE - translation of > and < resp. > and < - wrong shortcut for encoded_tag_closed and encoded...
[Resolved] ACE - translation of > and < resp. > and < - wrong shortcut for encoded_tag_closed and encoded...
This thread is resolved. Here is a description of the problem and solution.
Problem: The client was experiencing issues with the Advanced Translation Editor (ATE) where symbols such as were being replaced by placeholders like 'encoded_tag_open' and 'encoded_tag_closed'. This was preventing the client from seeing the actual text and copying the translated text to add these markers afterwards. Solution: We identified that the ATE was encoding these symbols to prevent them from being interpreted as HTML, which is standard behavior to avoid breaking the XML during content transfer. The client was advised to use the previous version of ATE (Gen2), which does not present this issue, until a fix for the latest version (Gen3) is released. This fix is currently in testing and expected to be included in the upcoming ATE release. We apologize for any inconvenience and are working on improvements.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If further assistance is needed, please do not hesitate to open a new support ticket at WPML support forum.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Background of the issue:
I am trying to translate some texts containing > and and <, they are defined as encoded_tag_closed and encoded_tag_open in ACE. Link to a page where the issue can be seen: hidden link
Symptoms:
The symbols are replaced by encoded_tag_closed etc. I don't see the text - just these 'encoded_tag...'. The keyboard shortcut for accepting them is shown as 'Alt+1', but after rolling back to a previous version, I found that it's 'Alt+Ctrl+1'. It's not possible to copy the translated text and to add these markers afterwards.
Questions:
Why are the symbols replaced by encoded_tag_closed and encoded_tag_open?
How can I copy the translated text and add these markers afterwards?
According to the description of this behavior, it seems that ATE is encoding the opening and closing tags so it doesn't get interpreted as HTML. The same way it creates tags for 'bold' or 'H1' tags.
In any case, could you share a screenshot of the original content with the tags and another screenshot of what you see in ATE? This will help me to better understand this scenario.
The site's theme is DIVI. I have done screenshots of the text in visual and text mode.
In the ATE screenshot you can see that the "plain" > is interpreted as encoded_tag_closed.
As a remark: this site is a copy of the already existing site gts-keramik.de - and there I have these texts already translated - some time ago.
And last but not least: the shown shortcut "Alt + 1" is wrong - I can only save translation, if I mark the tag and confirm with "Alt + Ctrl + 1".
Hi Elke,
Thank you very much for sharing this information
I consulted my colleagues about the tags, and this is the expected behavior because the opening and closing tags break the XML that is sent with the content, that's why they are substituted by a tag in ATE.
Regarding the Alt+1, I'll have to check that in ATE. Could you share the access credentials to the site in your next message and share the URL of a page where I can see the Alt+1 issue?
After talking to my colleagues about some other behaviors we found, I decided to escalate this ticket to our 2nd tier of support so our development team can take a closer look at this and try to find a better solution for future releases.
I have to admit - I'm confused: everything is much better in this environment now ...
It is immediately noticeable that the keyboard shortcut for the encoded hint is now correct (see the attached screenshot and the one from October 31) - and the functionality is also there.
But on the production environment the problem is still there - although all plugins etc. are at the same level.
