Tradurre i template Elementor e Divi senza rompere i layout

Hai fatto tutto correttamente. Hai acquistato un tema premium, hai trovato il file .po, lo hai tradotto con cura e hai caricato il file .mo nella tua cartella delle lingue. Le stringhe nell'header del tema si aggiornano correttamente. Il footer è in spagnolo. Il tuo checkout WooCommerce è localizzato. Ma poi apri la homepage e ogni singolo titolo, pulsante e blocco di testo costruito con Elementor è ancora in inglese.

Controlli il file .po. Puoi vedere le stringhe inglesi nel codice. Riprovi a tradurre. Nulla cambia. Svuoti le cache. Nulla cambia. Ti convinci che qualcosa si è rotto finché qualcuno in un forum ti fa notare gentilmente: Elementor (e Divi, e Beaver Builder, e Bricks) non memorizzano il contenuto nei file .po. Non l'hanno mai fatto. Hai combattuto un problema che non è risolvibile con l'approccio che stai usando.

Questa guida spiega perché il contenuto del page builder è architettonicamente diverso dal contenuto di temi e plugin, i due percorsi per tradurlo e come mantenere intatto il markup dei widget durante la traduzione in modo che i tuoi layout attentamente progettati non si sfaldino.

Perché Elementor e Divi non usano i file .po

I file .po memorizzano le stringhe che vivono nel codice – chiamate come __( 'Shop', 'mytheme' ) sparse nei template PHP. Lo strumento di compilazione WP-CLI può estrarre queste stringhe in un template .pot, i traduttori lavorano sui file .po e i file .mo compilati vengono caricati a runtime.

Il contenuto del page builder è diverso. Quando digiti "Benvenuti nel nostro negozio" in un widget di intestazione di Elementor, quel testo non si trova in nessun file PHP. Viene salvato come JSON (Elementor) o come blob di shortcode (Divi) nella tabella wp_postmeta, associato al post in cui lo hai inserito.

Dove si trova effettivamente il contenuto del page builder

Elementor memorizza l'albero dei widget di ogni pagina in postmeta sotto la chiave _elementor_data. Apri qualsiasi post nel database e troverai un array JSON che descrive ogni sezione, colonna e widget, con impostazioni e contenuto in linea:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi memorizza il contenuto delle sue pagine come shortcode incorporati in post_content:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder e Oxygen seguono lo stesso schema con il loro formato. Nessuno di questi contenuti viene mai toccato dai file .po / .mo.

Cosa vive nei file .po

Il plugin del page builder stesso ha stringhe UI – etichette dei pulsanti nell'editor, messaggi di errore, avvisi di amministrazione. Questi si trovano nei file .po e vengono tradotti dai tuoi file .mo in wp-content/languages/plugins/. Questo è di solito il motivo per cui le persone si confondono: traducono le stringhe di "Elementor" e vedono l'interfaccia utente dell'editor in spagnolo, ma il contenuto effettivo che hanno costruito con quei widget rimane in inglese.

Questa distinzione è anche la causa principale della metà dei ticket nella nostra guida alla risoluzione dei problemi per le traduzioni che non vengono visualizzate – il lettore si aspetta che i file .mo influenzino il contenuto che vede sul front end, ma il contenuto è nel database, non nel codice.

Cosa coprono effettivamente i file .po su un sito con page builder

Lasciami tracciare una linea chiara tra i due in modo che tu sappia esattamente cosa gestisce ogni tipo di file.

I file .po / .mo traducono

• Le stringhe del template del tema: get_template_part, testo hardcoded in header.php, footer.php, functions.php.
• Le stringhe UI del plugin: checkout WooCommerce, etichette admin di Yoast, etichette dei campi di Contact Form 7.
• L'UI del plugin page builder: pulsanti dell'editor di Elementor, messaggi di conferma del salvataggio di Divi.
• Stringhe dinamiche che i plugin fanno eco al front end: WooCommerce "Aggiungi al carrello", "Esaurito", totali del carrello.

I file .po / .mo NON traducono

• Testo di titoli, paragrafi, pulsanti digitato nei widget di Elementor.
• Didascalie di immagini, effetti hover, titoli di accordion all'interno dei moduli Divi.
• Contenuto in template riutilizzabili, sezioni globali, blocchi salvati.
• Etichette CSS personalizzate o script in linea all'interno dei widget del builder.

Ecco perché la documentazione degli autori di temi sulla traduzione è tecnicamente corretta ma spesso inutile per gli utenti finali. La nostra guida su come localizzare qualsiasi tema WordPress copre approfonditamente il lato del tema – questo post riprende da dove finisce quello.

Due percorsi per la localizzazione del page builder

Ci sono esattamente due modi per tradurre il contenuto del page builder, ed entrambi presentano dei reali compromessi.

Percorso uno: Duplicare le pagine per lingua

Usa un plugin multilingue come WPML, Polylang o TranslatePress. Crea una copia di ogni pagina per lingua. In Elementor, duplichi l'intero layout e scambi il testo su ogni copia. In Divi, copi il blob di shortcode e traduci il testo tra i tag.

Pro: Ogni lingua può avere layout progettati in modo indipendente (utile quando il testo tradotto è più lungo e rompe il tuo design originale). Piena compatibilità con l'editor visuale del page builder.

Contro: Scalabilità lineare – 5 lingue significano 5x il lavoro di layout. Ogni modifica del design deve essere applicata 5 volte. Il database cresce rapidamente. Il caching diventa più difficile.

Percorso due: Livello di traduzione delle stringhe

Alcuni plugin (Polylang Pro, il modulo String Translation di WPML, TranslatePress) possono esporre singole stringhe all'interno dei widget del page builder per la traduzione, quindi scambiarle al momento del rendering. Mantenere un unico layout e il plugin traduce le stringhe sul posto.

Pro: Unica fonte di verità per il layout. Le modifiche al design si applicano ovunque.

Contro: Minore flessibilità quando il testo tradotto cambia drasticamente lunghezza. Alcuni widget (quelli complessi con contenuti annidati, elenchi dinamici, moduli) non espongono le stringhe in modo pulito. Costo di performance per ogni rendering.

Il nostro confronto Polylang vs WPML vs TranslatePress copre i compromessi di ogni plugin più in dettaglio.

Mantenere il markup dei widget al sicuro durante la traduzione

Qualunque percorso tu scelga, il contenuto tradotto deve preservare il markup strutturale del builder. Se il tuo traduttore elimina uno shortcode di Elementor, sostituisce un attributo di dati o riordina i tag annidati, il widget viene renderizzato in modo errato.

Zone di pericolo di Elementor

I widget di Elementor incorporano shortcode e tag dinamici all'interno delle impostazioni di testo. Il campo del titolo di un widget di intestazione può contenere:

Welcome to <strong>our</strong> [user_name] store

Quel [user_name] è un tag dinamico: Elementor lo sostituisce con il nome dell'utente loggato al momento del rendering. Se la traduzione lo deforma, agli utenti verrà visualizzato letteralmente "[user_name]".

Le icone all'interno dei pulsanti utilizzano attributi di classe che non devono essere tradotti. Il testo alternativo dell'immagine è memorizzato separatamente dall'URL dell'immagine. I layout di colonna utilizzano impostazioni specifiche per breakpoint (title_mobile, title_tablet) che richiedono una gestione individuale.

Annidamento di shortcode Divi

Gli shortcode di Divi si annidano profondamente: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Un traduttore che tratta il blob come testo semplice codificherà le parentesi quadre, tradurrà i valori degli attributi o perderà i tag di chiusura. Qualsiasi di queste azioni corrompe il modulo e Divi si rifiuta di renderizzarlo.

Il modello sicuro

Per entrambi i builder, la traduzione deve:

1. Analizzare il formato del widget (JSON per Elementor, AST di shortcode per Divi).
2. Percorrere l'albero identificando solo i campi di testo visibili all'utente.
3. Bloccare shortcode, tag dinamici, attributi HTML e CSS in linea.
4. Inviare solo le superfici di testo al traduttore con il contesto.
5. Reinserire il testo tradotto nella struttura originale.

Questo è lo stesso principio che il nostro motore applica ai file .po. La guida alla traduzione dei file .po senza rompere le variabili di codice illustra in dettaglio i modelli %s e placeholder – l'equivalente per il page builder sono gli shortcode e i tag dinamici.

Un flusso di lavoro ibrido che funziona davvero

Per la maggior parte dei team, la risposta pratica è combinare entrambi gli approcci.

Fase 1: Tradurre l'interfaccia utente di temi e plugin tramite file .po

Esporta i file .pot dal tuo tema e dai plugin chiave (WooCommerce, Yoast, UI del page builder). Traducili una volta tramite un traduttore cloud che rispetta il formato .po. Inserisci i file .mo compilati in wp-content/languages/. Questo gestisce l'80% delle stringhe dell'interfaccia del tuo sito con una manutenzione continua quasi nulla.

Fase 2: Scegliere un plugin multilingue per i contenuti dinamici

Installa Polylang o WPML per i contenuti di post, pagine e prodotti. Configura la struttura URL (/es/, /fr/) e i tag hreflang. Questo ti fornisce l'infrastruttura per i contenuti del database per lingua.

Fase 3: Duplicare selettivamente i template del page builder

Per le landing page ad alto traffico, le homepage e i contenuti di marketing fondamentali, duplica la pagina in ogni lingua e traduci manualmente i widget. Ottieni il controllo completo del design dove conta.

Fase 4: Utilizzare la traduzione delle stringhe per i blocchi ripetuti

Per le sezioni globali, i template riutilizzabili e le CTA nel footer che appaiono su ogni pagina, utilizza la funzione di traduzione delle stringhe del tuo plugin multilingue. Aggiorna in un unico posto, scambia al momento del rendering.

Fase 5: Eseguire controlli di qualità

Il contenuto del page builder tradotto dovrebbe essere renderizzato senza spostamenti di layout. Le lingue più lunghe (tedesco, russo) rompono le larghezze dei pulsanti. Le lingue più corte (cinese, giapponese) lasciano spazi bianchi scomodi. Testa ogni template per lingua prima del rilascio.

Errori comuni e come evitarli

Alcune trappole che compaiono in ogni progetto di localizzazione di page builder.

Il testo Alt delle immagini non viene tradotto

Sia Elementor che Divi memorizzano il testo alt per istanza del widget, non nella Libreria Media. La traduzione dell'immagine originale non traduce il testo alt in ogni widget che la utilizza. Aggiorna il testo alt in ogni pagina duplicata.

Moduli e campi personalizzati

I moduli di contatto incorporati nei widget del page builder hanno le proprie stringhe (etichette, segnaposto, messaggi di convalida). Consulta la nostra guida alla traduzione di Gravity Forms e Contact Form 7 per il lato dei moduli.

Widget e template globali

Le modifiche a un template globale si propagano a ogni pagina che lo utilizza, comprese le copie tradotte. Questo può essere utile o catastrofico a seconda che tu voglia contenuti condivisi o separati. Decidi esplicitamente per ogni template.

Scadenza della cache di traduzione

I page builder memorizzano aggressivamente l'HTML renderizzato nella cache. Dopo la traduzione, svuota tutte le cache, inclusa la cache CSS di Elementor (Elementor > Strumenti > Rigenera CSS) e la cache CSS statica di Divi.

Mettendo tutto insieme

Tradurre un sito costruito con Elementor o Divi non è più difficile che tradurre un tema statico – richiede solo il giusto modello mentale. Le stringhe di temi e plugin vivono nei file .po e viaggiano tramite i file .mo. Il contenuto del page builder vive nel database e viaggia tramite plugin multilingue o duplicazione manuale. Confondere i due percorsi è la fonte più comune di frustrazione per il "perché le mie traduzioni non funzionano".

Il flusso di lavoro vincente è noioso: file .mo statici per tutto ciò che vive nel codice, plugin multilingue per il contenuto delle pagine e cura manuale per le landing page di alto valore. Nessun singolo strumento gestisce tutti e tre, e chiunque ti prometta il contrario ti sta vendendo qualcosa.

Pronto a tradurre i tuoi file .po di temi e plugin senza rompere il markup dei widget? Prova SimplePoTranslate gratuitamente – non è richiesta alcuna carta di credito. Carica .po, scarica traduzioni sicure, inseriscile in wp-content/languages/.