[Fermé] translating a Divi Theme Builder template

The only global template that I couldn't translate with ATE is this one : lien caché

And I do see the stuck template parts : lien caché

Is that the template you are talking about?

Turns out the XLIFF that is sent to translation editor exceeds 1MB. Since your current file is above it, you will need to reduce its size. Or use a different translation methode.

The size could be explained by the use of multiple dynamic Woocommerce Divi blocks in a single page, the metadata is big for those blocks. Which significantly increases the file size. Consider removing or extracting this data before translation.

You can also try translating it using https://wpml.org/documentation/translating-your-contents/using-different-translation-editors-for-different-pages/#how-to-use-manual-translation or through CTE.

To switch from the Advanced Translation Editor (ATE) to the Classic Translation Editor (CTE) in WPML, follow these steps:

1. Navigate to WPML -> Settings.

2. On the settings page, locate the option for "Editor for new translations."
- Select "Classic Translation Editor."

3. After setting the editor to CTE, create a new translation job
- Follow the prompts to create a new translation job for the desired page.

Once done, you can switch it back to ATE again. Let me know if you'd like me to do it.

Do you agree on switching to CTE (Classic Translation Editor) editor for these blocked templates? If yes, I can start the translation for you and you can review it later,

Then I will activate the intial editor (ATE, Advanced translation editor).

So for blocked content, use CTE and for all rest, use ATE.

I need your confirmation to understand how you would like to proceed,

Hello Roamin,

You can use CTE in any case you want, but I recommend to only use it in case you see another template with a huge XLIFF file.

To debug the exact content, you can download the XLIFF file of the stuck translation job and inspect its content to find the cause, here are the steps :

1. Go to WPML > Translation Management > Translators, add yourself as a translation manager by choosing "Select an existing user and set as Translator", and then do the same to Add a Translator.
2. Send the job to translation.
3. Go to WPML > Translations and download all jobs, which will include the XLIFF files : lien caché
4- You will see then if any of the files exceeds that limit, see which block is too big.

The limit is strictly 1MB because it is a huge indicatiom that the text file is too big > Leads to issues related to automatic translation, usually it wouldn't even reach 0.1MB , we cannot change this limit.

And you are right, CTE doesn't have automatic translation,

Okay I did a proper debug with one example "panier", here is what I found :

The failing XML is valid XML. I do not see malformed XML, broken CDATA, unbalanced shortcodes, or HTML tags.
The actual bad unit for exemple in panier.xliff is "

- trans-unit id="package-string-40-10051"
- module: et_pb_wc_cross_sells
- group: Main Content/Row

That unit is the problem because this single shortcode is bloated by corrupted Divi metadata:
- source length: 17,210 chars
- global_colors_info attribute alone: 16,960 chars
- repeated refs:%22sale_badge_color%22: 360
- %22title_text_color%22: 360
- %22price_text_color%22: 15

So the failure is not file size in the normal sense. It is one huge Divi global_colors_info attribute full of repeated global color mappings. WPML/ATE is likely treating this as an oversized/invalid tag payload and surfacing it as “file size limit exceeded / execution expired”.

Locally, the same corruption exists in the DB on:
- wp_posts.ID = 17323
- post_type = et_pb_layout
- post_name = panier
- post_title = panier1
so for other layouts I'm suspecting similar issues,

Best fix: open Divi Library layout , edit/recreate the Woo Cross Sells module, and save so Divi regenerates global_colors_info. A DB-level fix would be to remove or normalize only the global_colors_info="..." attribute from that et_pb_wc_cross_sells shortcode; the visible colors are already stored in normal attributes like price_text_color="#896214".

The next step is to detect the exact block for each blocked layout to see if the pattern is consistant,

Let me know if you have any questions,

Hi Romain,

Ilyes is currently away but I have marked your ticket to remain open.

once you are ready please come back and we will continue where we left off.

Sounds good, thank you!