This thread is resolved. Here is a description of the problem and solution.
Problem: You need to translate scripts within a post, such as iframes or shortcodes, for different languages. However, when using the Advanced Translation Editor (ATE), you encounter issues where the original language script appears blank and modifications in the new language do not save correctly. After editing and saving the post, scripts revert back to the original language. Solution: We recommend not using the ATE for pages that contain scripts you need to translate. Instead, use a different method to manage translations for these specific pages to avoid the issues you're experiencing. For detailed guidance on how to implement this, please refer to our documentation on using different translation editors for different pages: Using Different Translation Editors for Different Pages.
If this solution does not apply to your case, or if it seems outdated, 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. Should you need further assistance, 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.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
What I meant is that, in my experience, we haven't had clients needing to translate thousands of scripts, so we lack extensive use cases for this.
I don't think making scripts translatable is feasible. It's not just about ATE; much of our content goes to external translators and agencies. If they don't understand the code, they might translate script texts, potentially breaking the websites. For example, today, a client translated IDs for sections linked to JavaScript, which caused functionality issues because the IDs no longer matched the code triggers.
The more complex the script, the higher the risk of errors.
Regarding the last point, if you think this solution might work for your use case, let me know. I can prepare a sandbox for testing to see how we can translate it without causing issues.
I have set up a sample display with both the original situation and the new option to be tested or worked on hopefully someone can supply a solution to this.
I did not translate though - explained why on the page.
I have supplied some basic info and images etc to explain the situation to whomever may look at it.
Let me know if you need more of anything - but it should be pretty clear on the page.
Thats fantastic - it appears to work and will hopefully do the trick!
2 questions:
1. How can you get the Shortcodes to automatically appear in the ATE (without having to remember the shortcode name and search for it)?
2. Can you assist with the issue of the field populating the URL in the script field of the ATE - it is overwriting /wanting to add the URL to all HTML element fields.
I know it is kind of a 2nd issue (also arose from trying to solve this one) but you have some familiarity with the issue so far and would save a whole lot of confusion trying to explain to the next supporter.
Translations all work perfectly and XML registration also now allows the shortcodes to appear in the main ATE without having to search.
Just on the Translation Memory part - This means that I cannot ever use the Elementor HTML widget (or maybe even the Text Widget) with any code that begins with <script> (irrespective of any differences within the code).
They will always populate that URL in the secondary language field.
Is there anything that I could add in front of existing scripts that will throw off Translation Memory but not affect or appear on the translated page if I leave the translation field empty?
For example any invisible code or masking to solve this.
Also is there a way to NOT display those HTML Script fields anymore so nobody will accidentally add anything to those fields?
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
You can use such scripts but if you translate the URL for this it will be populated because translation memory will match it. There is no way around this.
Also fields that appear in translation editor must be filled in, they can't be left empty otherwise the translation will not get saved 100%.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
Can you share credentials for hidden link and tell me on which page does it occur? I can't seem to access the site using provided credentials no longer.
2. Regenerate the translation jobs on your site to ensure the changes take effect (so just resave the hidden link after making a minor change there (like adding "test" to the title).
Thank you for the code - however I haven't tried it just yet.
I was translating posts all day yesterday with no issues.
I created a new post today and when I went to translate it - a 2700 word (approx) post used 11,000+ credits...
Upon scrolling through it appears the post now shows twice. Once as per normal (text editor fields), then directly below that now appears wpml_string_wrapper_content fields.
Is there something you may have done yesterday/this morning while looking for the solution above?
this is the post in the ATE: hidden link
About halfway down the page, you will see the repeated fields as per the image.