Dlaczego niektóre bloki wymagają "Attempt Recovery" po tłumaczeniu?

Plik wpml-config.xml dostarczany przez wtyczki nie zawsze jest idealny. Tłumaczenie może być poprawne, ale HTML przechowywany przez edytor może odbiegać od tego, czego oczekuje blok — kliknięcie Attempt Recovery odbudowuje go.

Przetłumaczony blok zakładek Kadence wyświetlający powiadomienie Attempt Recovery

Jeśli potrzebujesz integracji z konkretną wtyczką, a jej wpml-config.xml ma problemy, skontaktuj się z nami — przyjrzymy się temu i sprawdzimy, czy problemy można naprawić po naszej stronie.

Przykład z Kadence. HTML bloku zawiera transformacje ciągów wejściowych, których nie można przetłumaczyć przez zwykłe zastąpienie ciągu. Na przykład w kadence/tabs zakładka zatytułowana "First tab" daje następujący wynik w renderowanym HTML:

<li id="tab-firsttab"

Dlatego tłumaczenie na hiszpański wymaga:

<li id="tab-primerapestaa"

…ale ta transformacja nie jest zadeklarowana w wpml-config.xml, więc blok nie może jej automatycznie naprawić. HTML frontendu nadal wygląda poprawnie, dlatego "Attempt Recovery" jest opcjonalne.

Przykład z Greenshift. Plik wpml-config.xml Greenshift deklaruje ten sam ciąg jako dwa niezależne tłumaczenia. Gdy dwa tłumaczenia nie są zgodne, blok musi zregenerować swój HTML — właśnie to robi Attempt Recovery. Na przykład w poniższym fragmencie <xpath>//*[contains(@class, 'gspb_button_wrapper')]</xpath> i <key name="buttonContent" /> odwołują się do tego samego ciągu:

<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>