Suporte de tradução para construtores de páginas chegando ao WPML

Há dois dias, realizamos uma pesquisa perguntando como você gostaria de traduzir sites criados com construtores de páginas. Neste post, eu gostaria de compartilhar os resultados e como isso influenciará nosso próximo desenvolvimento no WPML 3.6.

Um pouco de contexto – Como recomendamos traduzir sites com construtores de páginas hoje

Para todos os construtores de páginas, exceto o Toolset Layouts, a única maneira de traduzir hoje é criar designs separados por idioma.

Isso é utilizável, mas não muito conveniente. Achamos que seria mais fácil criar o design uma vez, para os idiomas, e apenas traduzir os textos com o WPML. A propósito, estamos concluindo a documentação sobre como traduzir tudo no Toolset, incluindo layouts. Escreverei sobre isso quando estiver pronto.

P: Você está satisfeito com o método atual de tradução de conteúdo criado com construtores de páginas?

Algumas pessoas realmente preferem criar designs separadamente por idioma. Isso faz sentido quando todo o design precisa ser ajustado. Eu acho que, se você tem um design muito preciso para a página inicial do site, faz sentido ajustar e otimizar por idioma.

A maioria está OK com o que temos agora, mas prefere ter um único design e traduzir com o WPML. E alguns dizem que essa abordagem não é utilizável para eles. Eu acho que essas são pessoas que usam serviços de tradução. Concordo que é praticamente impossível pedir a tradutores externos que mexam nos designs do seu construtor de páginas. Enfrentamos esses problemas ao integrar o WPML a vários serviços de tradução.

P: Quais construtores de páginas você usa com frequência?

Quase 60% dos sites que usam construtores de páginas usam o Visual Composer. Os próximos construtores muito populares são o Divi e o Avada. Outros também são bastante populares.

Como será o processo de tradução?

Como já temos isso totalmente integrado e funcionando com o plugin Layouts (embora a documentação ainda esteja “em andamento”), usarei o Layouts como meu exemplo.

Passo 1) Crie o design no construtor de páginas

Como expliquei, você só precisará criar o design uma vez no construtor de páginas. O mesmo design será usado para todas as traduções.

Passo 2) Envie para tradução

Quando uma página usa um construtor de páginas, você precisará traduzi-la “duas vezes”. A primeira vez a página, o que incluirá o título da página e quaisquer campos personalizados que você usar. A segunda vez é o design do construtor de páginas. Eu sei que isso é um pouco trabalhoso. Trabalharemos para automatizar isso, mas provavelmente não na primeira rodada.

Vá para WPML->Gerenciamento de tradução. Lá, você verá novos tipos de conteúdo para os designs do construtor de páginas. Selecione os designs que você quer traduzir e envie para tradução. Você pode passar por diferentes elementos do seu site e adicionar à Cesta de tradução. Quando terminar de escolher o que traduzir, vá para WPML->Gerenciamento de tradução->Cesta de tradução e envie tudo junto em um único lote. Você pode traduzir localmente (com o Editor de tradução do WPML) ou externamente para o seu serviço de tradução favorito.

Passo 3) Traduza

Você verá todos os textos que pertencem ao design, lado a lado. Você está traduzindo apenas os textos e não a estrutura. Traduza e marque cada campo como “completo”. Quando você salva, as traduções são aplicadas automaticamente ao design do construtor de páginas.

Passo 4) Veja os resultados no front-end

Suas traduções aparecerão no front-end, quando você visualizar o conteúdo. Você não verá nenhuma tradução no construtor de páginas, porque as traduções não o alteram.

Passo 5) Atualize a tradução quando o design for atualizado

Se você editar o design no construtor de páginas, vá para o Painel de tradução e reenvie para tradução. Apenas os textos modificados aparecerão para tradução.

Roteiro para integração da tradução para construtores de páginas com o WPML

Estamos começando a integração com o Visual Composer, que infelizmente é o menos conveniente de se integrar. O VC armazena o design como shortcodes dentro “do conteúdo”. Os shortcodes não têm IDs, então é difícil associar um elemento e seus textos. Tentaremos trabalhar com os autores do VC para adicionar IDs às células. De qualquer forma, usaremos um método alternativo que identifica strings de acordo com seu conteúdo. Isso significa que, se um texto mudar, você precisará traduzi-lo do zero, porque não temos como saber qual era aquele texto antes de você editar a célula. Faremos o nosso melhor para adicionar IDs às células do VC. Espero que você perceba que isso não está inteiramente em nossas mãos.

Outros construtores de páginas funcionam de forma diferente. Eles armazenam o design do construtor separadamente “do conteúdo” e as células têm identificadores exclusivos. Assim, quando você editar uma célula, verá a tradução anterior e poderá apenas atualizá-la.

O WPML 3.6 certamente incluirá suporte para o Visual Composer. Tentaremos incluir suporte para o Divi também. Como parte deste ciclo de versão, também escreveremos uma documentação detalhada sobre como registrar strings para tradução em construtores de páginas. É bem simples, só requer documentar isso adequadamente.

Em seguida, trabalharemos com todos os outros desenvolvedores de construtores de páginas para integrar esse suporte aos seus produtos.

Feedback?

Como isso soa para você? Tenho certeza de que algumas pessoas vão querer que trabalhemos em outros construtores de páginas primeiro. Temos que priorizar, então estamos começando com o que a maioria das pessoas usa. Garantiremos chegar a TODOS os construtores de páginas eventualmente, e quanto antes, melhor. Eu gostaria de receber seu feedback sobre o processo de tradução e o plano geral. Se você tiver alguma ideia, dúvida ou sugestão, deixe seus comentários e eu responderei.