Tradurre un sito WordPress: plugin, architetture e flusso di lavoro
Come rendere multilingue il sito di un'azienda manifatturiera, comprese le schede prodotto, l'area download e i documenti di conformità, senza doverlo rifare.
Il sito di un costruttore non è un sito vetrina
WordPress regge una quota rilevante dei siti aziendali italiani, comprese moltissime imprese manifatturiere che esportano. Quando si affronta il tema del multilingue, però, quasi tutta la documentazione disponibile ragiona su siti editoriali o su piccoli negozi online, e le indicazioni che ne derivano si rivelano inadeguate appena si guarda a che cosa contiene davvero il sito di un costruttore di macchine.
Un sito di quel tipo ospita in genere quattro insiemi di contenuti molto diversi tra loro.
Il primo è il catalogo di prodotto: famiglie, modelli, varianti, dati tecnici, applicazioni. È contenuto strutturato, spesso costruito con tipi di contenuto personalizzati e campi aggiuntivi, e la sua traduzione è un lavoro sui campi, non sulle pagine.
Il secondo è l'area download, di solito riservata: manuali d'uso e manutenzione, schede tecniche, dichiarazioni di conformità, certificati, disegni, cataloghi ricambi. Sono file, e i file hanno un proprio ciclo di traduzione che il plugin non gestisce.
Il terzo sono i contenuti di supporto: casi applicativi, note tecniche, approfondimenti settoriali, articoli. È la parte che porta traffico organico nelle lingue di export ed è quasi sempre l'ultima a essere tradotta, quando invece è quella con il ritorno migliore.
Il quarto sono i contenuti di servizio: moduli di contatto, richiesta di assistenza, pagina delle sedi e dei distributori, testi legali, messaggi automatici. Sono pochi in volume e determinano se il contatto arriva o si perde.
La conseguenza è che la scelta dell'architettura multilingue non può essere fatta guardando ai confronti generici tra plugin. Va fatta guardando a come sono costruiti quei quattro insiemi nel sito specifico.
Le quattro architetture possibili
Prima dei nomi dei plugin conviene chiarire i modelli. Le soluzioni disponibili si riconducono a quattro architetture, e ciascuna ha implicazioni durature.
Contenuti duplicati nella stessa installazione
Ogni contenuto ha una controparte per ciascuna lingua, collegata all'originale da una relazione di traduzione. Tutto vive in un unico sito, con un'unica base di dati e un unico insieme di utenti. È il modello di gran lunga più diffuso. Permette di differenziare le lingue anche nella struttura, ossia di avere pagine che esistono solo in alcune lingue, cosa spesso necessaria quando le gamme di prodotto variano da mercato a mercato. In compenso appesantisce la base di dati e le interrogazioni.
Rete di siti collegati
Ogni lingua è un sito autonomo dentro una rete, e un livello di collegamento tiene in relazione i contenuti corrispondenti. È l'architettura più solida quando i mercati hanno esigenze molto diverse — temi differenti, gamme differenti, redazioni locali autonome — e quando si vuole isolare le prestazioni di ciascun sito. Richiede però competenze di sistema superiori e rende più oneroso ogni intervento trasversale.
Traduzione sul livello di presentazione
Il contenuto originale resta uno solo e la traduzione viene applicata al testo prodotto dalle pagine, intercettandolo. Il vantaggio è che nessuna parte del sito sfugge: qualunque testo appaia a schermo, compreso quello generato da estensioni di terze parti, è traducibile. Lo svantaggio è che si perde in gran parte la possibilità di differenziare struttura e contenuti per mercato, e che le prestazioni dipendono da come è gestita la memorizzazione delle traduzioni.
Servizio esterno che serve le versioni tradotte
Le pagine tradotte sono generate e distribuite da un servizio esterno, con un'integrazione leggera sul sito. È l'avvio più rapido in assoluto e il modello con la minore autonomia: i contenuti tradotti non sono un patrimonio del sito ma un servizio in abbonamento, e uscirne richiede una migrazione.
La scelta tra questi modelli va fatta rispondendo a tre domande: le gamme di prodotto sono uguali in tutti i mercati? Esistono redazioni locali che devono poter pubblicare in autonomia? Quanto a lungo deve durare l'assetto? Le risposte selezionano il modello meglio di qualunque confronto di funzionalità.
I plugin più diffusi e che cosa cambia davvero
Con i modelli in mente, i nomi diventano meno importanti. Vale però la pena chiarire dove si collocano le soluzioni che ricorrono in ogni valutazione.
WPML implementa il modello a contenuti duplicati ed è la soluzione commerciale più matura per i siti complessi. Il motivo per cui compare quasi sempre nei siti industriali è la sua gestione dei campi personalizzati, dei tipi di contenuto su misura e delle tassonomie, oltre alla possibilità di esportare i contenuti in formato XLIFF e reimportarli. Per chi lavora con un fornitore linguistico esterno questa è la funzione decisiva.
Polylang implementa lo stesso modello ed è disponibile anche in versione gratuita. È leggero e lineare; la gestione dei campi personalizzati e l'esportazione strutturata richiedono la versione professionale o integrazioni aggiuntive. Per siti con struttura semplice e catalogo contenuto è una scelta efficiente.
TranslatePress lavora sul livello di presentazione, con un'interfaccia di traduzione visuale. Il suo punto di forza è che intercetta anche i testi prodotti da estensioni che non prevedono alcun supporto multilingue: nei siti stratificati negli anni è spesso l'unica soluzione che copre tutto. Il suo limite è la minore capacità di differenziare i contenuti per mercato.
MultilingualPress adotta il modello a rete di siti e ha senso quando la scelta di fondo è già stata presa in direzione della rete, tipicamente per ragioni organizzative.
Weglot e soluzioni analoghe rientrano nel modello a servizio esterno.
Nessuno di questi strumenti traduce: gestisce traduzioni. La qualità linguistica dipende da chi scrive i testi, non dal plugin. La funzione automatica integrata in molti di essi produce una prima stesura, che va sottoposta a revisione umana: è la lavorazione disciplinata dalla norma ISO 18587 sul post-editing della traduzione automatica, e i servizi di post-editing esistono per governarla in modo verificabile. Pubblicare traduzione automatica non rivista su schede tecniche, avvertenze e testi legali è una scelta che prima o poi presenta il conto.
Le stringhe del tema e delle estensioni
Una parte del testo che appare sul sito non è contenuto redazionale: è scritta dentro il tema o dentro le estensioni. Etichette dei pulsanti, intestazioni di sezione, messaggi di errore dei moduli, testi delle notifiche, indicazioni di navigazione. Se questa parte non viene tradotta, il sito risulta bilingue a metà, e in genere resta in italiano proprio dove serve capire: nei messaggi che dicono se una richiesta è andata a buon fine.
WordPress gestisce queste stringhe con un sistema di internazionalizzazione consolidato, basato sulle funzioni di traduzione e su file di catalogo. Ogni componente dichiara un proprio spazio dei nomi, e le traduzioni vengono caricate in base alla lingua attiva. Nelle versioni recenti della piattaforma è stato introdotto un formato di caricamento più efficiente, che migliora sensibilmente i tempi di risposta sui siti con molte traduzioni caricate.
Che cosa significa in pratica per chi commissiona il lavoro:
- Il tema su misura va verificato: se le stringhe non sono state dichiarate come traducibili, nessun plugin potrà tradurle e occorre un intervento sul codice. È la verifica da fare per prima, perché è l'unica che può richiedere sviluppo.
- I temi e le estensioni di terze parti hanno spesso traduzioni ufficiali per le lingue principali, e vanno recuperate prima di ritradurre da zero.
- Le traduzioni personalizzate delle stringhe non vanno inserite modificando i file originali, perché ogni aggiornamento le cancella. Vanno collocate dove la piattaforma le conserva.
- I moduli di contatto meritano un controllo dedicato: etichette dei campi, testi di aiuto, messaggi di validazione, testo del consenso al trattamento dei dati e messaggio di conferma. È il percorso su cui arriva il contatto commerciale.
I contenuti che i plugin non vedono
È il capitolo che manda fuori tempo e fuori budget i progetti apparentemente semplici. Alcune categorie di testo non vengono intercettate dalle configurazioni predefinite, e chi non le cerca le scopre a sito pubblicato.
I campi personalizzati. Nei siti industriali i dati tecnici sono quasi sempre campi aggiuntivi associati ai prodotti. Ogni campo va dichiarato come traducibile oppure come copiabile senza traduzione, distinguendo tra testo — che va tradotto — e valori numerici, codici e riferimenti, che vanno replicati identici. Questa configurazione è una parte sostanziale del lavoro di impostazione e va fatta campo per campo.
I contenuti dei costruttori di pagine. Le pagine composte con costruttori visuali salvano il testo insieme alle informazioni di impaginazione, in strutture annidate. L'estrazione richiede il supporto specifico del plugin multilingue per quel costruttore, e i risultati variano. Va provato su una pagina reale prima di impegnare l'intero sito.
Le tassonomie. Categorie, famiglie, settori applicativi, etichette: sono testo, compaiono nei menu e negli indirizzi delle pagine, e vanno tradotti insieme alle rispettive descrizioni.
I menu e i widget. Ogni lingua ha bisogno del proprio menu, perché la struttura può differire, e i blocchi ricorrenti di piè di pagina contengono spesso testo non gestito dal flusso principale.
I metadati per i motori di ricerca. Titoli, descrizioni e testi delle anteprime social sono gestiti da estensioni dedicate e vanno tradotti esplicitamente. Restano in italiano più spesso di quanto si creda, e sono ciò che l'utente legge nei risultati di ricerca.
I testi delle immagini. Testo alternativo, didascalie e descrizioni della libreria media sono contenuto: servono all'accessibilità e all'indicizzazione.
I documenti allegati. Manuali, schede tecniche e dichiarazioni di conformità sono file caricati nella libreria media. Il plugin può associare a ogni lingua il file corrispondente, ma la traduzione del documento è un lavoro a sé, che riguarda il contenuto tecnico e la sua impaginazione.
L'area download e i documenti di conformità
Per un costruttore, l'area download è spesso la parte del sito più visitata dai clienti esistenti. Merita un trattamento distinto perché non è fatta di pagine ma di documenti, e perché alcuni di quei documenti hanno rilevanza normativa.
Le istruzioni per l'uso sono soggette a obblighi linguistici. La Direttiva 2006/42/CE richiede che la macchina sia accompagnata dalle istruzioni nella lingua dello Stato membro in cui è immessa sul mercato; il Regolamento (UE) 2023/1230, che la sostituisce, conferma il principio e disciplina espressamente la possibilità di fornire le istruzioni in formato digitale a determinate condizioni, prevedendo tra l'altro che l'utilizzatore possa ottenerne una versione su carta. Un'azienda che sposta il manuale dall'imballo all'area riservata del sito sta compiendo una scelta che ricade in questo quadro e che va verificata con il proprio consulente.
Le dichiarazioni di conformità, i certificati e le schede di sicurezza hanno analogamente requisiti propri, che variano a seconda del tipo di prodotto e del mercato di destinazione.
Da questo discendono alcune indicazioni pratiche per l'area download:
- Associare esplicitamente ciascun file alla lingua e alla revisione a cui si riferisce, e mostrarla all'utente.
- Non far scaricare il documento italiano quando manca la versione nella lingua richiesta: è preferibile segnalarne l'assenza.
- Mantenere lo storico delle revisioni, perché una macchina in servizio da anni ha bisogno della propria versione del manuale, non dell'ultima.
- Trattare la traduzione dei documenti con la stessa memoria usata per il sito, così che il termine usato nella scheda prodotto online coincida con quello del manuale. È il perimetro della traduzione tecnica, e la resa impaginata dei documenti richiede un intervento specifico sui file sorgente.
Indirizzi, hreflang e visibilità nelle lingue di export
Un sito multilingue mal segnalato ai motori di ricerca è un sito che esiste e che non viene trovato. Le regole sono poche e vanno applicate tutte.
Le versioni linguistiche vanno dichiarate reciprocamente con le annotazioni hreflang: ogni pagina elenca le proprie corrispondenti nelle altre lingue e dichiara anche sé stessa. I codici sono quelli standard, ISO 639-1 per la lingua ed eventualmente ISO 3166-1 alpha-2 per il Paese, ed è opportuno prevedere un valore predefinito per il pubblico non coperto dalle versioni disponibili. Le pagine dichiarate devono essere indicizzabili: una versione esclusa dall'indicizzazione e al tempo stesso dichiarata come alternativa è un segnale contraddittorio.
Gli indirizzi delle pagine vanno tradotti. Un sito in tedesco i cui indirizzi contengono ancora le categorie italiane comunica che la traduzione è superficiale, e perde le occorrenze delle parole chiave nel percorso. Fanno eccezione i codici articolo, che conviene lasciare invariati perché sono ciò che i clienti cercano.
I canonici devono puntare alla pagina della stessa lingua, non alla versione italiana: è l'errore di configurazione più frequente e ha l'effetto di far sparire dall'indice l'intera versione tradotta.
La mappa del sito deve includere tutte le versioni linguistiche.
Vale poi un'avvertenza di metodo che va oltre la configurazione: tradurre non è posizionare. Le parole con cui un tecnico tedesco cerca un componente non sono la traduzione delle parole con cui lo cerca un tecnico italiano. Una ricerca delle parole chiave condotta nella lingua di arrivo, prima della traduzione, cambia il risultato in modo sostanziale, e a volte suggerisce di riorganizzare le pagine invece di tradurle. L'argomento è trattato per esteso nella guida alla SEO multilingue.
Il flusso di lavoro con un fornitore linguistico
Ci sono due modi di far tradurre un sito WordPress da un fornitore esterno, e la differenza tra i due si misura in ore di lavoro sprecate.
Il primo è dare accesso all'ambiente di amministrazione. I traduttori lavorano dentro l'editor del sito, vedendo il contesto. È comodo per interventi piccoli e per le rifiniture; è inefficiente su volumi consistenti, perché impedisce l'uso della memoria di traduzione e dei controlli automatici di qualità, rallenta il lavoro e obbliga a distribuire credenziali di accesso a un sistema di produzione.
Il secondo è esportare i contenuti e lavorarli in un ambiente di traduzione. È il metodo corretto sopra la soglia di poche pagine. Il formato di riferimento è XLIFF, standard OASIS che separa il testo traducibile dalla struttura, trasporta le note e conserva lo stato di ciascuna unità. I contenuti escono, vengono tradotti con memoria e glossario, rientrano e mantengono l'impaginazione originale.
I vantaggi non sono teorici. La memoria evita di ritradurre ciò che è già stato tradotto: su un sito industriale, dove le schede prodotto condividono blocchi interi di testo, la quota riutilizzata è elevata. Il glossario impone la terminologia approvata dall'ufficio tecnico. I controlli automatici intercettano numeri alterati, unità di misura sbagliate, segnaposto persi e incoerenze terminologiche. Il funzionamento di questi strumenti è descritto nella pagina dedicata a memorie di traduzione e strumenti CAT.
Una raccomandazione operativa: stabilire un ordine di lavorazione e rispettarlo. Prima la struttura di navigazione e i testi di servizio, poi le pagine istituzionali, poi il catalogo, poi i contenuti di supporto. Pubblicare una lingua a metà è peggio che non pubblicarla, perché il visitatore incontra l'italiano nel punto sbagliato e conclude che il sito non è mantenuto.
La pagina dedicata alla traduzione di siti web descrive il perimetro dell'intervento; quando il progetto comprende un catalogo transazionale valgono anche le considerazioni raccolte a proposito della traduzione di un sito e-commerce.
Prestazioni, manutenzione e conformità
Tre aspetti che si manifestano dopo la pubblicazione e che vanno previsti prima.
Prestazioni. Un sito multilingue moltiplica i contenuti e, a seconda dell'architettura, il numero di interrogazioni alla base di dati. Le contromisure sono note: memorizzazione delle pagine generate, memorizzazione degli oggetti in memoria, distribuzione statica dei contenuti attraverso una rete di consegna, ottimizzazione delle immagini. Va verificato che il sistema di memorizzazione distingua correttamente le lingue: una configurazione errata serve la pagina italiana a un visitatore tedesco, ed è un difetto che sfugge ai controlli interni perché chi prova il sito dall'Italia non lo vede.
Manutenzione. Ogni aggiornamento del sito genera testo nuovo. Serve una procedura che rilevi i contenuti modificati e li invii in traduzione, e serve un responsabile interno che la presidi. In assenza, le lingue secondarie si fermano nel giro di pochi mesi e il divario diventa incolmabile. Vale la pena decidere fin dall'inizio quali contenuti si aggiornano in tutte le lingue e quali possono restare disallineati senza danno.
Accessibilità. I requisiti richiamati negli appalti pubblici europei per i prodotti e servizi informatici sono raccolti nella norma EN 301 549, che per i contenuti web recepisce i criteri delle WCAG. Alcuni di questi criteri riguardano direttamente il multilingue: la dichiarazione della lingua della pagina e la marcatura dei passaggi in lingua diversa servono ai lettori automatici. È un intervento di poche righe che nei siti tradotti manca quasi sempre.
Protezione dei dati. Informativa privacy, banner sui cookie e testi di consenso ricadono nel Regolamento (UE) 2016/679 e devono essere forniti in forma comprensibile: significa nella lingua del destinatario, con la terminologia definita dal regolamento. Il tema è approfondito nella pagina dedicata a GDPR e traduzione dei dati.
Il quadro operativo con cui Italtrust affronta questi progetti è quello consueto: sede a Roma, oltre 3.000 linguisti madrelingua, ottanta lingue di lavoro, certificazioni ISO 17100 e ISO 27001, piattaforma CAT proprietaria con memorie condivise tra sito, catalogo e documentazione, cifratura AES-256 e conformità al GDPR sui materiali affidati.
Errori ricorrenti
Il breve elenco che segue raccoglie i difetti che si ripresentano in quasi tutti i progetti WordPress multilingue del settore industriale.
Scegliere il plugin prima di aver esaminato il sito. L'architettura giusta dipende da come sono costruiti catalogo e campi personalizzati, non dal confronto tra funzionalità.
Non verificare il tema su misura. Se le stringhe non sono state predisposte per la traduzione, serve un intervento sul codice, e va saputo prima di fissare le scadenze.
Dimenticare i metadati per i motori di ricerca. Restano in italiano e compaiono nei risultati di ricerca, vanificando il lavoro fatto sulle pagine.
Lasciare i canonici puntati alla versione italiana. Fa sparire dall'indice l'intera versione tradotta.
Pubblicare traduzione automatica non rivista su schede tecniche, avvertenze e testi legali.
Tradurre le pagine e non i documenti scaricabili, che sono la parte del sito con maggiore valore d'uso per i clienti esistenti.
Non prevedere chi mantiene le lingue. È la causa più frequente dei siti multilingue che dopo un anno sono aggiornati solo in italiano.
Checklist per un sito WordPress multilingue
Scegliere l'architettura, non il plugin
Contenuti duplicati, rete di siti, livello di presentazione o servizio esterno: decide la struttura del catalogo.
Verificare le stringhe del tema
Se il tema su misura non le dichiara traducibili serve un intervento sul codice, da pianificare subito.
Configurare i campi personalizzati
Distinguere campo per campo ciò che va tradotto da ciò che va replicato identico, come codici e valori.
Esportare in XLIFF
Lavorare in un ambiente di traduzione con memoria e glossario invece di dare accesso all'amministrazione.
Controllare hreflang e canonici
Dichiarazioni reciproche, valore predefinito impostato e canonici puntati alla pagina della stessa lingua.
Presidiare l'area download
File associati a lingua e revisione, storico conservato, terminologia allineata a quella del sito.
Domande frequenti su WordPress multilingue
Un WordPress multilingue che si mantiene da solo
Indicateci struttura del sito, plugin già installati e documenti dell'area download: verifichiamo l'architettura, il flusso di esportazione e le lingue da attivare.