Perché alcuni blocchi richiedono "Attempt Recovery" dopo la traduzione?

Il wpml-config.xml fornito dai plugin non è sempre perfetto. La traduzione può essere corretta, ma l'HTML memorizzato dall'editor può divergere da ciò che il blocco si aspetta — fare clic su Attempt Recovery lo ricostruisce.

Blocco di schede Kadence tradotto che mostra l'avviso Attempt Recovery

Se hai bisogno di un'integrazione con un plugin specifico e il suo wpml-config.xml presenta dei problemi, contattaci — daremo un'occhiata e vedremo se i problemi possono essere risolti dalla nostra parte.

Esempio Kadence. L'HTML del blocco contiene trasformazioni di stringhe di input che non possono essere tradotte tramite una semplice sostituzione di stringa. Ad esempio, su kadence/tabs, una scheda intitolata "First tab" produce questo nell'HTML renderizzato:

<li id="tab-firsttab"

Quindi la traduzione spagnola richiede:

<li id="tab-primerapestaa"

…ma questa trasformazione non è dichiarata in wpml-config.xml, quindi il blocco non può correggerla automaticamente. L'HTML del frontend continua ad apparire corretto, da cui il fatto che "Attempt Recovery" sia facoltativo.

Esempio Greenshift. Il wpml-config.xml di Greenshift dichiara la stessa stringa come due traduzioni indipendenti. Quando le due traduzioni non corrispondono, il blocco deve rigenerare il proprio HTML — è ciò che fa Attempt Recovery. Ad esempio, nello snippet seguente <xpath>//*[contains(@class, 'gspb_button_wrapper')]</xpath> e <key name="buttonContent" /> fanno riferimento alla stessa stringa:

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