Da WPML a Polylang: perché ho cambiato plugin multilingua per WordPress

Per molti anni WPML è stato il mio plugin multilingua di riferimento: l'ho installato, configurato e mantenuto su decine di siti WordPress, ne conosco pregi e scorciatoie. Oggi, sui progetti nuovi e quando se ne presenta l'occasione su quelli esistenti, uso Polylang. Non è una questione di moda né di prezzo: è che, a mio avviso, WPML è diventato difficile da usare, soprattutto per chi il sito lo deve gestire ogni giorno. Qui spiego cosa è cambiato, come ragiono quando scelgo e come si affronta una migrazione senza perdere traduzioni né posizionamento.

Due modi diversi di intendere il multilingua

WPML e Polylang risolvono lo stesso problema con filosofie opposte. WPML è un ecosistema: un plugin principale affiancato da moduli per la traduzione delle stringhe, la gestione dei flussi di traduzione, WooCommerce, ACF e altro ancora. Registra le relazioni tra le lingue in tabelle proprie del database e propone un proprio editor di traduzione, pensato per lavorare per segmenti di testo e per affidare il lavoro a traduttori interni o esterni.

Polylang parte dall'idea opposta: stare il più vicino possibile al funzionamento nativo di WordPress. Le lingue sono gestite come una tassonomia, le traduzioni sono collegate tra loro senza tabelle aggiuntive e ogni versione tradotta è una pagina WordPress normale, che si apre e si modifica nello stesso editor dell'originale. Non c'è un secondo ambiente da imparare: si cambia lingua e si lavora come sempre.

Perché ho smesso di usare WPML

Un pannello sempre più complesso

Con gli anni WPML si è arricchito di funzioni, e con le funzioni sono arrivati menu, impostazioni e passaggi intermedi. Per tradurre una pagina, il percorso predefinito passa dall'editor di traduzione avanzato e dai lavori di traduzione; per una stringa di un tema o di un plugin serve un altro modulo; per i campi personalizzati occorre decidere, campo per campo, se copiarli, tradurli o ignorarli. Per uno sviluppatore è gestibile. Per una segreteria o un ufficio marketing che deve correggere un testo in inglese, diventa un ostacolo.

Il cliente deve poter lavorare da solo

Il punto, per me, è proprio questo. Costruisco siti in cui il cliente compone le pagine con blocchi Gutenberg arricchiti da campi ACF, e li aggiorna in autonomia. Se poi la versione inglese si modifica in un ambiente diverso, con regole diverse, quell'autonomia si perde e le richieste di assistenza aumentano. Con Polylang la versione tradotta si gestisce esattamente come quella italiana: stessi blocchi, stessi campi, stessa interfaccia.

Leggerezza e manutenzione

Meno moduli significa meno aggiornamenti da coordinare, meno incompatibilità tra versioni e meno codice eseguito a ogni richiesta. Su siti che curo nel tempo, la differenza si sente nella manutenzione quotidiana: il numero di moduli da coordinare può ridursi. Verifico comunque gli aggiornamenti di entrambi i plugin su staging, con prove sulle lingue, sui campi personalizzati e sui flussi del negozio, se presente.

Cosa offre Polylang nel lavoro reale

La versione gratuita copre il necessario per un sito istituzionale: lingue, pagine, articoli, categorie, menu e un selettore di lingua. La versione Pro aggiunge ciò che serve su un progetto professionale, come la traduzione degli slug degli URL, la duplicazione dei contenuti per partire dalla versione originale e l'integrazione con ACF, che copia o sincronizza i campi tra le lingue secondo le regole impostate.

Sul fronte SEO, Polylang genera gli attributi hreflang tra le versioni collegate e lascia scegliere la struttura degli indirizzi, con la lingua in una cartella, in un sottodominio o in un dominio diverso. Per i negozi online esiste un'estensione dedicata a WooCommerce, a pagamento, che gestisce prodotti, varianti e pagine del carrello nelle diverse lingue.

Quando WPML resta la scelta giusta

Non tutto è a favore di Polylang, e sarebbe scorretto dirlo. WPML resta più forte quando la traduzione è un processo strutturato: traduttori esterni, revisioni, servizi di traduzione professionale integrati e traduzione automatica a crediti. Anche un e-commerce complesso con più valute, gestito da WooCommerce Multilingual, può essere un buon motivo per restare. Se il sito vive di questi flussi, il pannello più complesso è il prezzo di funzioni che vengono davvero usate.

La domanda da porsi, quindi, non è quale plugin sia migliore in assoluto, ma chi tradurrà i contenuti e come. Se a farlo è il cliente stesso, dallo stesso pannello in cui gestisce il sito, Polylang è quasi sempre la scelta più semplice.

Come si migra da WPML a Polylang

Preparare il terreno

La migrazione si fa su una copia del sito, mai in produzione. Prima di tutto serve un backup completo di file e database, poi un inventario di ciò che è tradotto: pagine, articoli, tipi di contenuto personalizzati, tassonomie, menu, widget, stringhe del tema e campi ACF. È anche il momento giusto per annotare gli URL attuali di ogni lingua, che serviranno per il controllo finale.

Importare le traduzioni

Gli autori di Polylang mettono a disposizione un plugin di migrazione da WPML che importa lingue, collegamenti tra le traduzioni e stringhe. La procedura indicata dagli autori è disattivare WPML senza eliminarne i dati, attivare Polylang e il plugin WPML to Polylang, quindi avviare l’importazione da Strumenti → WPML Importer. Non si creano prima le lingue in Polylang: vengono importate. Al termine si disattiva il migratore e si verificano selettore di lingua, URL e traduzioni, controllando in particolare che la struttura degli indirizzi corrisponda a quella precedente.

Controllare tutto ciò che il plugin non vede

L'importazione automatica non copre ogni caso. Vanno ricontrollati i menu di ogni lingua, i widget, le stringhe tradotte del tema, le impostazioni dei campi ACF e, se presente, il negozio online. Poi si confrontano gli URL con l'inventario iniziale: ogni indirizzo deve rispondere come prima, e se qualcosa cambia servono redirect 301 puntuali per non disperdere il posizionamento. Infine si verificano hreflang e sitemap e si fa un giro completo del sito in ogni lingua prima della pubblicazione.

Una matrice di verifica per la migrazione

Prima dell’importazione costruisco un inventario con identificativo del contenuto, lingua, URL e collegamenti alle traduzioni. Dopo l’importazione confronto numero di contenuti, relazioni e risposte HTTP, includendo tipi di contenuto personalizzati e tassonomie.

Per i campi ACF distinguo valori traducibili, valori da copiare una sola volta e valori da sincronizzare. Provo esplicitamente repeater, riferimenti ad altri contenuti, immagini e blocchi: il fatto che il testo sia presente non dimostra che le relazioni puntino alla lingua corretta. Se c’è WooCommerce, il collaudo comprende varianti, carrello, checkout ed email per lingua.

Il database di partenza deve restare recuperabile. Il migratore non elimina i dati WPML e non sostituisce queste verifiche.

Riferimento: procedura ufficiale WPML to Polylang.

Come la vedo io

Un plugin multilingua non dovrebbe aggiungere un secondo modo di lavorare a WordPress, ma estendere quello che c'è già. È lo stesso principio con cui costruisco i siti: temi su misura, blocchi Gutenberg con campi ACF, pochi plugin scelti con cura e un pannello che il cliente sappia usare senza manuali. Polylang si inserisce bene in questo approccio; WPML resta uno strumento valido, ma per i progetti che seguo oggi è spesso più di quanto serva, e più difficile da gestire di quanto dovrebbe.

Perché affidarlo a me

Dal 1999 ho consegnato più di 300 progetti e collaboro con più di 30 agenzie, da Roma e da remoto. Ho usato WPML per anni e conosco bene entrambi i plugin: posso impostare un sito multilingua da zero o migrare un sito esistente da WPML a Polylang, curando URL, redirect e SEO.

Se hai un sito multilingua da costruire o da semplificare, scrivimi: in una chiacchierata di circa 20 minuti capiamo qual è la strada giusta. Il servizio è in Sviluppo WordPress.