FAQs
FAQsWhy do some blocks need "Attempt Recovery" after translation?

Why do some blocks need "Attempt Recovery" after translation?

The wpml-config.xml shipped by plugins isn't always perfect. The translation may be correct, but the editor's stored HTML can drift from what the block expects — clicking Attempt Recovery rebuilds it.

Translated Kadence tabs block displaying the Attempt Recovery notice
Translated Kadence tabs block displaying the Attempt Recovery notice

If you need an integration with a specific plugin and its wpml-config.xml has issues, please get in touch — we'll take a look and see if the issues can be fixed on our side.

Kadence example. The block's HTML contains transformations of input strings that can't be translated by a string replacement. For instance, on kadence/tabs, a tab titled "First tab" produces this in the rendered HTML:

<li id="tab-firsttab"

So the Spanish translation needs:

<li id="tab-primerapestaa"

…but this transformation isn't declared in wpml-config.xml, so the block can't auto-fix it. The frontend HTML still looks fine, hence "Attempt Recovery" is optional.

Greenshift example. Greenshift's wpml-config.xml declares the same string as two independent translations. When the two translations don't match, the block has to regenerate its HTML — that is what Attempt Recovery does. For instance, in the snippet below <xpath>//*[contains(@class, 'gspb_button_wrapper')]</xpath> and <key name="buttonContent" /> refer to the same string:

<gutenberg-block type="greenshift-blocks/button" translate="1" label="Advanced Button">
    <xpath>//*[contains(@class, 'gspb_button_wrapper')]</xpath>
    <key name="buttonContent" />
    <key name="label" />
    <key name="buttonLink" />
    <key name="customAnchor" />
    <key name="closeLabel" />
    <key name="openLabel" />
</gutenberg-block>