Skip to content Skip to sidebar

This thread is resolved. Here is a description of the problem and solution.

Problem:
You are trying to translate a published page using the + icons in the post edit UI. When you click on the +, it launches the Advanced Translation Editor (ATE) with all translations prefilled. After accepting and completing the translation, the ATE closes, and the + icon changes to a refresh icon, then a cog icon. However, the translated page is not accessible via the icon or the language dropdown, and there is a translation job marked as 'in progress' in the Translation Management > Translation jobs table that never completes.
Solution:
The issue occurs because the page contains an HTML block with a large JavaScript script, which breaks when ATE tries to translate it, resulting in an invalid XLIFF file. WPML then rejects this file. We recommend two possible workarounds:
1. Temporarily delete the problematic section and add it back after the translations are complete.
2. Avoid using ATE for this page. Instead, use the Classic Translation Editor (CTE) or the WordPress editor to manually edit the translations with Elementor. This method is more time-consuming but allows you to use the automatically translated texts from the translation memory.
We have escalated this issue to our developers for a permanent fix.

Please note that this solution might be outdated or not applicable to your specific case. We highly recommend checking for 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 the problem persists, please 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.

Tagged: 

This topic contains 1 replies, has 1 voice.

Last updated by Paola Mendiburu 8 months ago.

Assisted by: Paola Mendiburu.

Author Posts
April 25, 2025 at 1:03 pm #16968704

alexandreP-37

That is really helpful, muchas gracias Paola (veo que esta en Madrid!), at least now we know what the problem is.
We'll see on our end how to bypass the hurdle, thanks for providing alternative workarounds!

April 26, 2025 at 10:12 am #16970775

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

As soon as we hear back from the developers with the final solution, I’ll let you know right away.

May 14, 2025 at 1:33 pm #17032609

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Hi there!

I hope that everything is well.

I got an answer from our developers:
They noted that the root of the issue is inserting JavaScript directly into a page-builder HTML block. This approach is inherently risky because:

1. Conflict and breakage risk
Any small syntax error or interaction with other scripts can cause your page or translation workflow to fail.

2. Lack of loading control
You can’t easily specify when or where that script should run (for certain pages or languages), which leads to unpredictable behavior.

For best practices, please refer to this guide from WordPress:
https://wordpress.org/support/topic/best-practice-cssjs-in-custom-html-block/

So it is better to move that js code outside the page.