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.
WordPress 6.7 has introduced a new issue that impact translations, please update WooCommerce and WPML to the latest versions before you report issues. More about this here - https://wpml.org/errata/php-error-wp-6-7-notice-function-_load_textdomain_just_in_time-was-called/
No issues with the Classic WPML editor. But if I just open the post translation in the ATE, there are no HTML attributes' translations which were made and published before. Upon saving the new post translation (without HTML attributes translated, i.e. without re-making their translations), they will be deleted from the post translation. I mean the HTML attributes' translations which were (and are) not registered for translations automatically, but were selected manually via the ATE's search field and translated. There are no problems with making these translations. Once they are saved, they are published. I may see them saved upon opening of the ATE, but only as far as the original post kept intact. If I make any change of the original post (eg., add a space somewhere), the HTML attributes' translations will be wiped out upon just opening of the ATE.
For information, I have the followig string in my wp-config: define( 'WPML_TRANSLATION_AUTO_UPDATE_ENABLED', false );
But the issue persists even without it.
I'm not sure if the following is connected with the issue described above, but despite adding the HTML attributes' translations to the Glossary, they are not suggested by the ATE when I remake the HTML attributes' translations after whey were wiped out. (Probably, there is the issue with any HTML attributes' translations -- they are not 'covered' by Glossary.)
Another note, I have many identical HTML attributes in different posts. And I belive that there potentially may be (probably not!) a problem if I open the ATE with a translation of another post with the same attributes, keep them untranslated (that may be understood as a requirement to keep them identical to original ones in any translation) and save the translation (it's actually quite easy to do unintantially, since the HTML attributes are not registered for translations). But I tried as hard as I coould to exclude this possible reason of the problem. However, the problem persists.
In this connection I would like to ask if there is a way to require ALL URLs and HTML attributes to be registered for (required) translation? (I believe that this would resolve the issue since there are no problems with the translations of registered strings, including HTML-related.)
BTW, some of the HTML attributes I'm talking about are part of shortcodes, but I have the same problem with 'regular' attributes/URLs and believe that it is not caused by shortcodes.
Sorry it has taken a while for someone to get back to you.
If you already translated content with the Classic editor you are advised not to switch to the Advanced Translation Editor for the same content, as existing translations may be lost and you may need to re-translate some of the content.
So it is to be expected that content previously edited with the Classic editor, where HTML attributes were present in the content and translated, then translated in ATE, would lose any translations of the attributes.
The safest way to prevent this is to continue to use the Classic editor for such content.
I don't use the Classic editor. I switched to it only to try if the issue I described may be replicated there (it may not, as I said, so, the problem is connected to the ATE). After switching back to the ATE I re-translated HTML attributes (actually, I made it several times with more than one post and a couple of languages before applying for assistance).
So, you may just forget about everything I said about the Classic editor. Because it is unessencial. And your answer is only about the CE. That it why it may not help me in any way.
And I specifically said, that I know how to translate 'manually' HTML attributes using the ATE. The translation is not the issue. Overwritting of the translations (when they are made using the ATE) upon making any unrelated change of the post (more precisely, upon opening the translation with the ATE again) -- that is the issue.
I'm unable to reproduce the problem on my own site, so I've set up a test site on our sandbox server.
I can't reproduce the problem there, either, so I'd like to invite you to try and reproduce the problem in case I have the steps you are using wrong.
Use this link to log in to the back end of the site: hidden link
You'll note that I added a page "Has attributes", which includes a Custom HTML block with some markup, that includes a data-that attribute.
I translated the page using ATE, including searching for and translating the attribute (screenshot 1).
I visited the translated page on the front end and with the browser dev tools verified that the translated attribute was output (screenshot 2).
I then went back into ATE to edit the same post, exited, and checked the translated post on the front end again, with the same result, that the translated attribute was still output.
Can you please try to reproduce the problem on this sandbox site, and if you are able to indicate the steps you took to reproduce it.
Thank you for spending the time on that, although I still seem to be missing some final step to reproduce the problem.
From your initial statements, I have understood that simply re-opening an existing translation in ATE is sufficient to lose the existing translations of HTML attributes.
I edited your child test page, updated the translation so that the href attribute was translated a and saved the translation.
I confirmed on the front end that the attribute translation worked.
I then re-opened the translation in ATE, made no changes and simply used the back link to return to the post.
Upon checking the attribute, I see the translation is still intact.
I'm sorry for not repeating in the body of my original message the crucial information I included only in its subj (which I meant as a first - and the most important - sentence of my message): HTML attributes' translations overwritten in ATE after any original post update. Not right away, but upon opening of the translation in the ATE, however only after some (even insignificant) update of the original post (i.e. page, since posts do not have hierarchy which is connected somehow, as I discovered later, with the issue).
Sorry, I overlooked that, but I still can't reproduce the problem even when making minor changes to the original language post.
Could you please list the exact steps with which post you take to trigger the problem.
In my case, the steps which don't trigger the problem are
- Translate Test page no. 1 to Spanish (there was an existing translation which I updated; the href attribute was not translated—I'm guessing because of the problem you reported—and I provided a translation for it.
- Marked the translation as complete, returning to the site admin pages
- I visited the translation of the Test page no. 1 on the front-end and verified that the translation of the href attribute was used.
- I edited the English version of Test page no. 1 and made a minor edit to the post content, and updated the post.
- I clicked to edit the translation, which took me to the ATE editor. I exited ATE (with the back link) without making any changes, noting that the translation was no longer complete because of the minor edit to the content, which was no longer translated.
- I visited the Spanish version of the post on the front end and noted that the translation of the href was still used, i.e. the problem didn't occur.
- I then went back to edit the translation again, and completed the translation by updating the translation for the content which had been broken by the minor change above.
- I then went back to edit the original English version of the post and made another minor edit. This time I checked the checkbox when updating the post to say this was a minor edit and to not update the translation.
- I then edited the translation again, where this time—because of checking that setting—the translation remained complete.
- I exited ATE once more without making any changes, and then visited the post on the front end again, and once more verified that the translation of the href attribute was still being used.
What am I missing? Please describe the required steps.
I'm unable to reproduce the issue every single time. It means that the problem is dependent on some factors I currently may not indicate specifically. Preliminary, it seems like a page should be saved as a child one for the first time for the problem to appear. (But I have not tested it enough to be sure.) Probably it is also language-specific. (Althought I belive that I was able to reproduce it with the EN-ES pair, I may not repeat it right now for some reason.) Also, it may be dependent on the level of the hierarchy of the page. Anyway, I was able to reproduce it with page-id-99. It has original text in Russian (which is the primary for my site) and translation to English (its title is 'Ещё один тест 2'). With any update of the original text, the translation of the shortcode-attr appears to be overwritten upon oppening of the ATE. I was able to reproduce it several times with this page.
I keep editing the Russian page "Ещё один тест..." and making minor changes (e.g. to the title), then editing the English version in ATE, and exiting ATE without making any changes, and still the original translation of the title attribute persists.
I'm going to stop now and try again in the morning, maybe fresh eyes will reveal something.
As I see, the page I was talking about (page-id-99, now it's renamed to 'Ещё один тест 6') still has the issue I described. Specifically, the original text has the following string: '%D0%B5%D1%89%D1%91-%D0%BE%D0%B4%D0%B8%D0%BD-%D1%82%D0%B5%D1%81%D1%82-2' (this is an escaped to-be-anchor), and the manual translation of this string does not survive any update of the original page. BTW, I was able to reproduce the problem before even with unescaped strings, that is why I belive that the escaping is not the trigger.
OK, we are specifically talking about translating the anchor attribute. The translation of the title attribute—which is the one I've been testing—never gets lost.
Now that I try translating the encoded anchor attribute, I see that it does get lost.
Let me do some more testing to see if I can isolate exactly what is required to reproduce this.
The title attribute is 'registered' for translation, i.e. when you open the ATE you see it on the left side, you should translate it for the translation to be completed. There are no problem with it or any such kind of 'registered' strings. The problem is with ones you should find manually with the search box to be translated. Normally, when you manually translated smth it stays translated and visible upon opening of the ATE after updating the original post. When there is an issue, you open the ATE after original post update and don't see those strings. If you found them manually again, you see that they are not translated. Besides the plugin's strings, it happens for me, for example, with 'regular' URLs having hash. I translate them manually, because hashes are in different languages (escaped, if necessary), they are added to ULRs, which are also in different languages.
Thanks for your patience while I've done some fairly exhaustive testing on this.
I have only ever been able to reproduce the problem translating from Russian to English, where the page being translated has a parent that is already a grandchild page, where non-Latin characters are included in the page title, and where the attribute content is encoded. I can consistently reproduce the problem in such a scenario, but minor variations typically work as expected.
I have passed all of the details on to the second tier team for them to investigate further, and so I'll escalate this thread and update you as soon as they get back to me.
