I contenuti dinamici sono il punto in cui la traduzione di WordPress diventa difficile

Perché la traduzione ordinaria degli articoli si ferma al confine dell’editor

La parte più semplice della traduzione di WordPress è il testo che si trova nel contenuto dell’articolo, perché ha un oggetto sorgente chiaro, un’assegnazione linguistica stabile e un punto prevedibile nell’editor. Gli strumenti di traduzione di solito possono leggere quel contenuto, creare una versione specifica per lingua e mantenere intatta la relazione tra le versioni.

Il contenuto dinamico rompe questo modello. Se il testo viene assemblato in un secondo momento da un widget, uno shortcode, una callback di rendering di un blocco, un template di plugin o una richiesta AJAX, potrebbe non esistere mai come singolo campo modificabile all’interno dell’articolo stesso. Ciò significa che il livello di traduzione non può fare affidamento sulle stesse regole di archiviazione e mappatura che usa per i contenuti ordinari.

La conseguenza pratica è che il comportamento multilingue dipende dal fatto che la superficie dinamica esponga input traducibili, memorizzi dati consapevoli della lingua o possa essere renderizzata in modo diverso per lingua al momento della richiesta. Se non lo fa, la pagina tradotta può comunque contenere frammenti non tradotti anche quando l’articolo principale è localizzato correttamente.

Quali superfici di WordPress richiedono di solito una gestione esplicita della compatibilità

Widget e barre laterali spesso contengono testo configurato al di fuori del principale editor degli articoli, quindi la traduzione deve arrivare nelle impostazioni del tema o del plugin e non solo nel contenuto dell’articolo.

Gli shortcode possono essere particolarmente difficili perché l’output visibile viene generato da attributi, opzioni memorizzate o dati del plugin che potrebbero non essere rappresentati come testo modificabile della pagina.

I blocchi possono essere statici o dinamici. I blocchi statici memorizzano il loro contenuto nell’articolo, ma i blocchi dinamici possono renderizzare da logica lato server, il che significa che il testo visibile viene prodotto in fase di esecuzione e può richiedere un supporto di traduzione separato.

L’output generato dai plugin, gli avvisi, le aree account e i frammenti caricati via AJAX sono anche punti di fallimento comuni perché vengono assemblati da dati di proprietà del plugin o da uno stato specifico della richiesta invece che dal solo corpo della pagina.

Queste superfici non sono automaticamente non tradotte in ogni configurazione, ma spesso si trovano al di fuori del normale percorso di traduzione e quindi richiedono una gestione esplicita della compatibilità per funzionare correttamente in tutte le lingue.

Il problema ingegneristico centrale: la traduzione ha bisogno di dati stabili, non solo di testo visibile

Un sistema multilingue può tradurre solo ciò che riesce a identificare e associare a una lingua. Questo di solito significa dati sorgente stabili, una relazione prevedibile tra oggetti e un modo per riprodurre lo stesso output in un’altra lingua senza rompere la pagina.

Il contenuto dinamico spesso dipende da meta dell’articolo, campi personalizzati, record di proprietà del plugin o condizioni di runtime. Se questi input non sono mappati su equivalenti linguistici, la pagina tradotta può renderizzare il testo sbagliato, l’oggetto collegato sbagliato o una miscela di lingue.

Ecco perché le relazioni tra contenuti sono importanti. Una pagina tradotta non è solo un problema di sostituzione del testo; è anche un problema di routing e associazione. Il sistema deve sapere quale articolo, termine, template o oggetto correlato tradotto usare quando il visitatore si trova sulla versione localizzata del sito.

Quando questa mappatura è incompleta, la modalità di errore è di solito una traduzione parziale piuttosto che un fallimento totale: la pagina si carica, ma alcuni frammenti restano nella lingua sorgente, puntano alla variante linguistica sbagliata o mostrano etichette e link incoerenti.

Il rendering in fase di esecuzione cambia il flusso di lavoro della traduzione

Il rendering dinamico significa che l’HTML finale non è completamente determinato quando l’articolo viene salvato. Invece, la pagina può essere assemblata in un secondo momento da template, logica di rendering dei blocchi, impostazioni del plugin o contesto della richiesta.

Questo cambia il flusso di lavoro della traduzione in due modi. Primo, il sistema di traduzione potrebbe dover tradurre la fonte dati sottostante invece dell’output renderizzato. Secondo, potrebbe dover rivalutare l’output a ogni richiesta in modo che la versione linguistica corretta venga assemblata in fase di esecuzione.

Questo è utile quando lo stesso template deve servire più lingue, ma crea anche un rischio di dipendenza. Se un componente dinamico legge da un’opzione condivisa, da un’impostazione globale o da un record neutro rispetto alla lingua, ogni lingua può ereditare lo stesso testo a meno che il componente non venga reso esplicitamente consapevole della lingua.

Per i proprietari di siti WordPress, la domanda operativa non è solo se la pagina possa essere tradotta, ma se il componente che genera la pagina sappia come scegliere i dati specifici della lingua corretta al momento del rendering.

Modalità di errore comuni nei siti WordPress multilingue

Una modalità di errore comune è la presenza di frammenti non tradotti all’interno di pagine altrimenti localizzate. Questo accade quando l’articolo principale è tradotto ma un widget, uno shortcode o l’output di un plugin legge ancora da un’impostazione nella lingua sorgente.

Un’altra è la rottura delle relazioni. Una pagina tradotta può collegarsi all’articolo correlato, prodotto, termine o vista account sbagliati se la mappatura dell’oggetto sottostante non è consapevole della lingua.

Anche il routing può fallire ai margini del contenuto dinamico. Se un componente genera link, segnali canonical o percorsi specifici per lingua senza rispettare la locale corrente, i visitatori possono essere inviati alla versione sbagliata del sito oppure i motori di ricerca possono ricevere segnali incoerenti.

Il contenuto AJAX aggiunge un ulteriore livello di rischio perché la pagina iniziale e il frammento caricato successivamente potrebbero non condividere lo stesso contesto linguistico, a meno che la richiesta non venga gestita esplicitamente in quel modo.

Le aree account e gli avvisi sono particolarmente sensibili perché spesso dipendono dallo stato dell’utente, dallo stato della sessione o da dati di proprietà del plugin. Queste superfici possono richiedere una logica di traduzione separata dal contenuto delle pagine pubbliche.

Cosa deve coprire di solito la gestione della compatibilità

La gestione della compatibilità deve generalmente rispondere a tre domande: dove si trova il testo, come è associato a una lingua e come viene renderizzato nel contesto corretto.

Se il testo si trova nei meta dell’articolo, nei campi personalizzati o nelle impostazioni del plugin, il livello di traduzione ha bisogno di un modo per memorizzare o fare riferimento a valori specifici per lingua.

Se il testo viene prodotto da un blocco, uno shortcode o una callback di template, la logica di rendering deve sapere quale versione linguistica produrre e quali oggetti correlati caricare.

Se l’output include link o destinazioni di navigazione, queste destinazioni devono risolversi sull’oggetto tradotto e non sull’oggetto sorgente originale.

Se l’output viene caricato in modo asincrono, la richiesta stessa deve portare abbastanza contesto linguistico affinché il frammento corrisponda alla pagina che il visitatore sta già visualizzando.