Come tradurre un sito WordPress

Tradurre un sito WordPress è una scelta architetturale, non un’attività di copywriting. Un moderno sito WordPress combina il markup dei blocchi Gutenberg, Advanced Custom Fields (ACF), metadati serializzati nel database e cataloghi WooCommerce. Per ampliare la traduzione senza rischi, occorre isolare i testi traducibili dalla sintassi interna del database.

WordPress alimenta oltre il 43% del web. La sua flessibilità lo ha reso la base di ogni tipo di sito, dai blog personali alle reti editoriali aziendali e ai grandi negozi WooCommerce.

Tuttavia, tradurre WordPress è notoriamente complesso. I contenuti non risiedono in un unico file di testo: sono distribuiti nelle tabelle del database MySQL (wp_posts, wp_postmeta, wp_terms), archiviati nei tipi di contenuto personalizzati, incorporati nei template dei temi e racchiusi nei commenti dei blocchi Gutenberg.

Ecco una guida architetturale per tradurre un sito WordPress in modo affidabile, senza compromettere il tema, corrompere i campi personalizzati o appesantire il database.

Confronto tra le 3 architetture di traduzione di WordPress

Ogni implementazione multilingue di WordPress si basa su una delle tre architetture fondamentali. Prima di scegliere uno strumento, è essenziale comprenderne i compromessi tecnici:

1. Duplicazione di record nel database (WPML, Polylang)

In questo modello tradizionale, il plugin di traduzione duplica ogni pagina, articolo e prodotto come record indipendente nella tabella wp_posts, collegandoli tramite tabelle relazionali del database.

• Come funziona: un articolo in inglese con ID 101 ha un articolo corrispondente in spagnolo con ID 102 e uno in tedesco con ID 103.
• I vantaggi: hai piena autonomia editoriale per ogni lingua. Puoi creare layout diversi, assegnare categorie specifiche e personalizzare le meta description SEO per ogni lingua.
• I costi nascosti: le dimensioni del database aumentano in proporzione al numero di lingue. In un negozio WooCommerce con 10,000 prodotti, aggiungere quattro lingue crea 50,000 record di post e centinaia di migliaia di righe wp_postmeta, con un possibile peggioramento significativo delle prestazioni delle query del database sugli hosting standard.

2. Traduzione con proxy edge dinamico (Weglot)

Invece di duplicare le righe del database, un proxy di traduzione si interpone tra il server WordPress e i visitatori, rilevando e traducendo le stringhe al livello DNS o di rete.

• Come funziona: il database WordPress rimane interamente in inglese. Il proxy intercetta le richieste delle pagine, sostituisce dinamicamente le stringhe e pubblica pagine già tradotte.
• I vantaggi: configurazione immediata e nessun appesantimento del database WordPress. Plugin e campi personalizzati non entrano mai in conflitto, perché il sito originale resta intatto.
• I costi nascosti: paghi un abbonamento SaaS mensile ricorrente, calcolato sul numero totale di parole tradotte. Se annulli l’abbonamento, le pagine tradotte scompaiono immediatamente.

3. Flusso di lavoro disaccoppiato basato su file (esportazioni XLIFF, PO e CSV)

I team aziendali moderni separano sempre più spesso la traduzione di WordPress esportando i contenuti traducibili in file di scambio standard (pacchetti WPML XLIFF/ZIP, esportazioni CSV di WooCommerce o file .po dei temi), perfezionandoli con motori di AI esterni e reimportando file puliti.

• I vantaggi: pieno controllo dei dati, senza eseguire modelli di AI impegnativi nell’ambiente PHP di WordPress. Puoi applicare i glossari del brand a migliaia di prodotti e scegliere tra i livelli di qualità Lite e Standard.

Le 4 insidie tecniche che compromettono le traduzioni WordPress

Tradurre i contenuti di WordPress con chatbot AI generici o strumenti di traduzione di base provoca spesso errori tecnici silenziosi:

1. Corruzione della sintassi dei blocchi Gutenberg

L’editor a blocchi Gutenberg di WordPress incorpora i parametri di layout nei delimitatori dei blocchi:

wp:paragraph {"fontSize":"large","className":"hero-lead"}
Welcome to our global platform.
/wp:paragraph

Gli strumenti di traduzione generici traducono spesso le chiavi JSON all’interno del delimitatore del blocco (ad esempio, trasformando "large" in "grand"), danneggiano la sintassi dei delimitatori o modificano le virgolette. Quando riapri il post nel pannello di amministrazione di WordPress, Gutenberg mostra l’errore irreversibile “Questo blocco contiene contenuti imprevisti o non validi”.

2. Corruzione degli array PHP serializzati in wp_postmeta

Advanced Custom Fields (ACF), le configurazioni dei widget e le opzioni dei temi memorizzano spesso dati strutturati sotto forma di stringhe PHP serializzate:

a:2:{s:5:"title";s:12:"Case Studies";s:4:"link";s:23:"https://example.com/cs/";}

In PHP serializzato, il marcatore s:12: dichiara esplicitamente che la stringa successiva è lunga esattamente 12 byte. Se uno strumento di traduzione non controllato traduce "Case Studies" in francese ("Études de cas", 14 byte) senza aggiornare il contatore dei byte, PHP non riesce a deserializzare la stringa (unserialize() restituisce false) e il campo personalizzato scompare completamente dal front-end.

3. Alterazione degli attributi degli shortcode

Molti temi meno recenti e page builder (Elementor, Divi, WPBakery) si basano sugli shortcode:

[cta_box title="Summer Sale" button_url="https://example.com" button_text="Shop Now"]

Gli strumenti di AI non controllati spesso traducono i nomi dei parametri funzionali (title=, button_url=) invece del solo testo visibile tra virgolette, rendendo lo shortcode del tutto inoperativo.

4. Disallineamento dei feed prodotto di WooCommerce e degli SKU

Le esportazioni di WooCommerce contengono decine di colonne operative che non vanno tradotte: ID, SKU, Tax:class, In stock?, Regular price, Attribute 1 name e Attribute 1 value.

Se chi traduce rende incoerenti gli attributi dei prodotti o modifica gli identificativi SKU, la sincronizzazione dell’inventario si interrompe e WooCommerce crea prodotti duplicati anziché traduzioni localizzate.

Il flusso di traduzione WordPress scalabile

Per localizzare in modo ordinato siti WordPress di grandi dimensioni, usa AI Glot per gestire il flusso di esportazione e importazione:

Passaggio 1: esporta i contenuti da WordPress

Esporta gli elementi da tradurre in base alla configurazione dei tuoi plugin:

• Da WPML: esporta i pacchetti di traduzione in formato XLIFF o come archivi ZIP.
• Da WooCommerce: usa l’esportatore integrato in Prodotti > Esporta per scaricare un file CSV.
• Da temi e plugin: individua i file di localizzazione gettext .po o .pot.

AI Glot supporta nativamente XLIFF, PO, POT, CSV e XLSX, oltre a più di 35 altri formati di localizzazione.

Passaggio 2: definisci l’ambito con un prompt in inglese semplice

Carica il file esportato su AI Glot e indica le tue regole in inglese semplice:

Translate the post_title and post_content fields into French and German. Preserve all Gutenberg block syntax (wp:...), shortcodes, and HTML markup. Leave IDs, URLs, and slugs untouched. Use formal register throughout.

Il motore separa il testo da tradurre dal codice strutturale, garantendo che la sintassi dei blocchi e gli attributi del database restino validi byte per byte.

Passaggio 3: controlla il piano deterministico e importa

Esamina il piano preliminare per verificare i campi rilevati, il conteggio delle parole da tradurre e il costo in crediti. Una volta approvato, scarica il file localizzato e importalo direttamente in WordPress tramite WPML o l’importatore CSV di WooCommerce.

In sintesi: crea un sito WordPress pronto a crescere a livello globale

La traduzione di un sito WordPress non dovrebbe mettere a rischio le prestazioni del database o il layout del tema. Abbinando formati di esportazione affidabili come XLIFF o CSV alla traduzione IA consapevole dello schema, puoi localizzare cataloghi aziendali e archivi di blog molto estesi in pochi minuti.

Prova i file esportati da WordPress con il campione gratuito di 5,000 parole di AI Glot: registrati gratis.