Supporto alla traduzione per i page builder in arrivo su WPML

Due giorni fa abbiamo condotto un sondaggio per chiederti come vorresti tradurre i siti progettati con i page builder. In questo articolo, vorrei condividere i risultati e come questi influenzeranno il nostro prossimo sviluppo su WPML 3.6.

Un po’ di contesto: come consigliamo di tradurre i siti con i page builder oggi

Per tutti i page builder, ad eccezione di Toolset Layouts, l’unico modo per tradurre oggi è creare design separati per ogni lingua.

Questo metodo è utilizzabile, ma non molto pratico. Pensiamo che sarebbe più facile progettare una sola volta per tutte le lingue e tradurre solo i testi con WPML. A proposito, stiamo completando la documentazione su come tradurre tutto in Toolset, inclusi i layout. Ne scriverò quando sarà pronta.

D: Sei soddisfatto del metodo attuale di traduzione dei contenuti creati con i page builder?

Alcune persone in realtà preferiscono progettare separatamente per ogni lingua. Questo ha senso quando l’intero design deve essere modificato. Immagino che, se hai un design molto accurato per la homepage del sito, abbia senso modificarlo e ottimizzarlo per ogni lingua.

La maggior parte è OK con ciò che abbiamo ora, ma preferisce avere un unico design e tradurre con WPML. Inoltre, alcuni dicono che questo approccio non è utilizzabile per loro. Penso che si tratti di persone che utilizzano i servizi di traduzione. Sono d’accordo che è quasi impossibile chiedere a traduttori esterni di toccare i design del tuo page builder. Abbiamo riscontrato questi problemi durante l’integrazione di WPML con diversi servizi di traduzione.

D: Quali page builder usi spesso?

Quasi il 60% dei siti che usano i page builder utilizza Visual Composer. I successivi builder molto popolari sono Divi e Avada. Anche altri sono piuttosto popolari.

Come sarà il processo di traduzione?

Dato che abbiamo già questa funzionalità completamente integrata e funzionante con il plugin Layouts (sebbene la documentazione sia ancora “in corso”), userò Layouts come esempio.

Passaggio 1) Progetta nel page builder

Come ho spiegato, dovrai progettare solo una volta nel page builder. Lo stesso design verrà utilizzato per tutte le traduzioni.

Passaggio 2) Invia alla traduzione

Quando una pagina utilizza un page builder, dovrai tradurla “due volte”. La prima volta la pagina, che includerà il titolo della pagina e tutti i campi personalizzati che utilizzi. La seconda volta il design del page builder. So che è un po’ una seccatura. Lavoreremo per automatizzarlo, ma probabilmente non nella prima fase.

Vai su WPML->Gestione traduzioni. Lì, vedrai nuovi tipi di contenuto per i design dei page builder. Seleziona i design che vuoi tradurre e inviali alla traduzione. Puoi scorrere i diversi elementi del tuo sito e aggiungerli al Carrello traduzioni. Quando hai finito di selezionare le traduzioni, vai su WPML->Gestione traduzioni->Carrello traduzioni e invia tutto insieme in un unico blocco. Puoi tradurre localmente (con l’Editor di traduzione di WPML) o esternamente presso il tuo servizio di traduzione preferito.

Passaggio 3) Traduci

Vedrai tutti i testi che appartengono al design, fianco a fianco. Stai traducendo solo i testi e non la struttura. Traduci e contrassegna ogni campo come “completo”. Quando salvi, le traduzioni vengono applicate automaticamente al design del page builder.

Passaggio 4) Guarda i risultati sul front-end

Le tue traduzioni appariranno sul front-end quando visualizzi il contenuto. Non vedrai alcuna traduzione nel page builder, perché le traduzioni non lo modificano.

Passaggio 5) Aggiorna la traduzione quando il design viene aggiornato

Se modifichi il design nel page builder, vai alla Dashboard di traduzione e invialo di nuovo alla traduzione. Solo i testi modificati appariranno per la traduzione.

Tabella di marcia per l’integrazione della traduzione per i page builder con WPML

Stiamo iniziando l’integrazione con Visual Composer, che sfortunatamente è il meno pratico con cui integrarsi. VC memorizza il design come shortcode all’interno de “il contenuto”. Gli shortcode non hanno ID, quindi è difficile fare un’associazione tra un elemento e i suoi testi. Cercheremo di collaborare con gli autori di VC per aggiungere gli ID alle celle. In ogni caso, useremo un metodo alternativo che identifica le stringhe in base al loro contenuto. Questo significa che, se un testo cambia, devi tradurlo da zero, perché non abbiamo modo di sapere quale fosse quel testo prima che tu modificassi la cella. Faremo del nostro meglio per aggiungere gli ID alle celle di VC. Spero tu ti renda conto che questo non è del tutto nelle nostre mani.

Altri page builder funzionano diversamente. Memorizzano il design del builder separatamente da “il contenuto” e le celle hanno identificatori univoci. Quindi, quando modifichi una cella, vedrai la traduzione precedente e potrai semplicemente aggiornarla.

WPML 3.6 includerà certamente il supporto per Visual Composer. Cercheremo di includere anche il supporto per Divi. Come parte di questo ciclo di rilascio, scriveremo anche una documentazione dettagliata su come registrare le stringhe per la traduzione nei page builder. È piuttosto semplice, richiede solo di essere documentato correttamente.

Successivamente, lavoreremo con tutti gli altri sviluppatori di page builder per integrare tale supporto nei loro prodotti.

Feedback?

Cosa ne pensi? Sono sicuro che alcuni vorranno che lavoriamo prima su altri page builder. Dobbiamo dare delle priorità, quindi iniziamo con quello che usa la maggior parte delle persone. Faremo in modo di raggiungere TUTTI i page builder alla fine, meglio prima che poi. Mi piacerebbe avere il tuo feedback sul processo di traduzione e sul piano generale. Se hai idee, domande o suggerimenti, lascia i tuoi commenti e ti risponderò.