Home›Support›English Support›[Escalated to 2nd Tier] HTML attributes' translations overwritten in ATE after any original post update
[Escalated to 2nd Tier] HTML attributes' translations overwritten in ATE after any original post update
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.
Elementor users - please update WPML to the latest version to maintain compatibility. More details here - https://wpml.org/changelog/2024/12/wpml-4-6-15-critical-update-for-elementor-sites/
I've just reproduced the problem with the EN-ES pair of languages and without any escaped characters (all latin ones). However, the page is a grandchild (no problems with this exact page when it's a child). Page id is 253, it's named '001'. You have actually tipped me when mentioned _grand_childness. I believe that this is the trigger of the problem. 'Manually' selected translations on grandchild (grandgrandchild and so on) pages doesn't survive any update of the original page.
Just an update to say that after some initial consultations with my colleagues this has now been escalated and handed over to the second tier team to investigate further, and I'll update you with their findings once they share them with me.
The sandbox site we were testing with—and where I was able to reliably reproduce the issue—expired before the second tier got to the internal ticket to investigate the problem, and so they created a new sandbox site with a similar set up.
But they are not able to reproduce the issue on the new test site, and when I edit it and use the same steps as previously, I can no longer reproduce the problem either.
Could you please try again yourself?
Here is a link to the back end of the site: hidden link
The steps were to add a page in Russian as a child of an existing grandchild page ("Third level") and to include in the content a shortcode which has attributes that need translating. Publish that page in Russian, create an English translation—including manually translating the shortcode attribute—and save, then make a minor change to the original Russian page.
When returning to ATE to update the translation, the attribute translations would be lost, although that is not happening currently, the attribute translations are preserved.
You can see in the content of the Russian pages that are children of "Third level" the shortcode that we are trying to translate.
Could you please check again to see if you can replicate the problem?
I reproduced the problem, using one of examples from my site. (Except, I have many such elements on every page and 39 languages, so you may understand what any change of an original grandchildpage -- it's nearly any 'content' page -- means for me))) For this reason, I used Russian language as a primary one and some escaped characters, but I belive that the issue is not dependend on these factors. (But definitely depended on some, which I don't fully realize.)
As you may see, I didn't use shortcodes -- the problem concernes URLs (and hashes) as well.
I have registered shortcodes' content for translation. However, I cannot workaround URLs/hashes this same way, cant't I?
I have been following comments on the internal ticket where I originally reported this which indicate that the problem should have been resolved (with an update to ATE), and so if you try again you shouldn't experience the problem any more.
Could you please check and let me know. (The updates are in ATE itself, so you shouldn't have to make any changes to your site, although I'd recommend making sure you are using the latest plugin versions.)
Unfortunately, I cannot confirm that the problem has been resolved. On the old pages as well as on the new one I created specifically for testing, the problem persists. I tested it with the simplest example: on an URL, including a hash. Specifically, I created a grandchild page with the following content: hidden link">Список ратификаций. As it should be, the URL was not included among the elements registered for automatic translation. So I translated the URL manually as follows: hidden link. After that I checked that the URL is displayed on the site according to my manual translation. I then made a minor change to the original page (replaced the full stop with an ellipsis) and saved the modified original. After that I opened the translation into English and - as before - found that the URL translation was not saved((
I have 4.5.14 version of the WPML plugin and believe that this is the latest available.
I don't still have the original test site so I set up a new site with the current WPML version to re-test the issue, and I'm back to the position of not being able to reproduce the issue.
In the screenshots you can see where I've searched and located a link (from your example in the last reply) and translated it. After completing the translation I went back and made a minor edit to the original (added the text "edit"), and in the second screenshot—which awaits the translation of "edit"—you can see the previously translated link is remembered.
Could I ask you again to test on my test server?
Log in with hidden link
I was editing and translating the page "RU Grandchild page".
I reproduced it on the 5th level (i.e. grand-grand-grandchild page, and this level is not the last one on my site) and with pages named in Russian -- this made URLs non-Latin too! For some reason, the problem is not reproducible if the page names are typed using Latin characters only. However, maybe it's not about levels and a type of characters but about the total length of an _escaped_ URL which is much longer with non-Latin characters and certainly longer with each new level. Actually, on my site, I made a first-level page name longer and was able to reproduce the problem on the 4th level.
@danielE-60 I checked the internal tickets and we don't have a solution, I'm afraid. I suggest you open a new thread so that we can confirm the specifics of your site, given that it is something which has proved difficult to reproduce. Please link to this thread so we can connect the tickets.
