Traduzir Modelos Elementor & Divi Sem Quebrar Layouts

Você fez tudo certo. Você comprou um tema premium, encontrou o arquivo .po, traduziu-o cuidadosamente e carregou o .mo para sua pasta de idiomas. As strings no cabeçalho do tema são atualizadas corretamente. O rodapé está em espanhol. Seu checkout do WooCommerce está localizado. Mas então você abre a página inicial e cada título, botão e bloco de texto construído com Elementor ainda está em inglês.

Você verifica o arquivo .po. Você pode ver as strings em inglês no código. Você retraduz. Nada muda. Você limpa os caches. Nada muda. Você se convence de que algo está quebrado até que alguém em um fórum gentilmente aponta: Elementor (e Divi, e Beaver Builder, e Bricks) não armazenam conteúdo em arquivos .po. Nunca armazenaram. Você tem lutado contra um problema que não é solucionável com a abordagem que está usando.

Este guia explica por que o conteúdo do construtor de páginas é arquitetonicamente diferente do conteúdo de temas e plugins, os dois caminhos para traduzi-lo e como manter a marcação do widget intacta durante a tradução para que seus layouts cuidadosamente projetados não se desfaçam.

Por que Elementor e Divi Não Usam Arquivos .po

Arquivos .po armazenam strings que vivem no código — chamadas __( 'Shop', 'mytheme' ) espalhadas por modelos PHP. A ferramenta de compilação WP-CLI pode extrair essas strings para um modelo .pot, os tradutores trabalham em arquivos .po, e os arquivos .mo compilados são carregados em tempo de execução.

O conteúdo do construtor de páginas é diferente. Quando você digita "Bem-vindo à nossa loja" em um widget de título do Elementor, esse texto não está em nenhum arquivo PHP. Ele é salvo como JSON (Elementor) ou um blob de shortcode (Divi) na tabela wp_postmeta, associado ao post onde você o colocou.

Onde o Conteúdo do Construtor de Páginas Realmente Vive

Elementor armazena a árvore de widgets de cada página em postmeta sob a chave _elementor_data. Abra qualquer post no banco de dados e você encontrará um array JSON descrevendo cada seção, coluna e widget, com configurações e conteúdo em linha:

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

Divi armazena o conteúdo de suas páginas como shortcodes incorporados em 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 seguem o mesmo padrão com seu próprio formato. Nenhum desses conteúdos é tocado por arquivos .po / .mo.

O Que de Fato Vive em Arquivos .po

O próprio plugin construtor de páginas possui strings de UI — rótulos de botões no editor, mensagens de erro, avisos de administração. Essas estão em arquivos .po e são traduzidas pelos seus arquivos .mo em wp-content/languages/plugins/. Esta é geralmente a razão pela qual as pessoas ficam confusas: elas traduzem strings do "Elementor" e veem a UI do editor em espanhol, mas o conteúdo real que construíram com esses widgets permanece em inglês.

Esta distinção é também a causa raiz de metade dos tickets em nosso guia de solução de problemas para traduções que não aparecem — o leitor espera que os arquivos .mo afetem o conteúdo que vê no frontend, mas o conteúdo está no banco de dados, não no código.

O Que os Arquivos .po Realmente Cobrem em um Site com Construtor de Páginas

Deixe-me traçar uma linha clara entre os dois para que você saiba exatamente o que cada tipo de arquivo gerencia.

Arquivos .po / .mo traduzem

• As strings de modelo do tema: get_template_part, texto hardcoded em header.php, footer.php, functions.php.
• Strings da UI de plugins: checkout do WooCommerce, rótulos de administração do Yoast, rótulos de campos do Contact Form 7.
• UI do plugin construtor de páginas: botões do editor Elementor, mensagens de confirmação de salvamento do Divi.
• Strings dinâmicas que os plugins ecoam no frontend: WooCommerce "Adicionar ao carrinho", "Sem estoque", totais do carrinho.

Arquivos .po / .mo NÃO traduzem

• Títulos, parágrafos, texto de botões digitados em widgets do Elementor.
• Legendas de imagens, efeitos de hover, títulos de acordeão dentro de módulos do Divi.
• Conteúdo em modelos reutilizáveis, seções globais, blocos salvos.
• Rótulos CSS personalizados ou scripts inline dentro de widgets do construtor.

É por isso que a documentação dos autores de temas sobre tradução é tecnicamente correta, mas muitas vezes inútil para os usuários finais. Nosso guia sobre como localizar qualquer tema WordPress cobre o lado do tema exaustivamente — esta publicação continua de onde aquela termina.

Dois Caminhos para Localização de Construtores de Páginas

Existem exatamente duas maneiras de traduzir o conteúdo do construtor de páginas, e ambas têm compromissos reais.

Caminho Um: Duplicar Páginas por Idioma

Use um plugin multilíngue como WPML, Polylang ou TranslatePress. Ele cria uma cópia de cada página por idioma. No Elementor, você duplica o layout inteiro e troca o texto em cada cópia. No Divi, você copia o blob de shortcode e traduz o texto entre as tags.

• Prós: Cada idioma pode ter layouts projetados de forma independente (útil quando o texto traduzido é mais longo e quebra seu design original). Compatibilidade total com o editor visual do construtor de páginas.
• Contras: Escala linear - 5 idiomas significam 5x o trabalho de layout. Qualquer mudança de design precisa ser aplicada 5 vezes. O banco de dados cresce rapidamente. O cache fica mais difícil.

Caminho Dois: Camada de Tradução de Strings

Alguns plugins (Polylang Pro, módulo de Tradução de Strings do WPML, TranslatePress) podem expor strings individuais dentro de widgets de construtores de páginas para tradução, e então trocá-las no momento da renderização. Você mantém um layout e o plugin traduz as strings no local.

• Prós: Fonte única de verdade para o layout. As alterações de design são aplicadas em todos os lugares.
• Contras: Menor flexibilidade quando o texto traduzido muda dramaticamente de comprimento. Alguns widgets (complexos com conteúdo aninhado, listas dinâmicas, formulários) não expõem strings de forma limpa. Custo de performance por renderização.

Nossa comparação Polylang vs WPML vs TranslatePress cobre os compromissos de cada plugin em mais detalhes.

Mantendo a Marcação do Widget Segura Durante a Tradução

Qualquer que seja o caminho escolhido, o conteúdo traduzido deve preservar a marcação estrutural do construtor. Se seu tradutor remover um shortcode do Elementor, substituir um atributo de dados ou reordenar tags aninhadas, o widget será renderizado quebrado.

Zonas de Perigo do Elementor

Widgets do Elementor incorporam shortcodes e tags dinâmicas dentro das configurações de texto. O campo de título de um widget de título pode conter:

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

Isso [user_name] é uma tag dinâmica — o Elementor a substitui pelo nome do usuário logado na renderização. Se a tradução o estragar, você obterá "[user_name]" literal exibido aos usuários.

Ícones dentro de botões usam atributos de classe que não devem ser traduzidos. O texto alt da imagem é armazenado separadamente da URL da imagem. Os layouts de coluna usam configurações específicas de breakpoint (title_mobile, title_tablet) que precisam de tratamento individual.

Aninhamento de Shortcodes Divi

Os shortcodes Divi se aninham profundamente: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Um tradutor que trata o blob como texto simples codificará colchetes, traduzirá valores de atributos ou perderá tags de fechamento. Qualquer um desses corrompe o módulo e o Divi se recusa a renderizá-lo.

O Padrão Seguro

Para qualquer construtor, a tradução deve:

1. Analisar o formato do widget (JSON para Elementor, AST de shortcode para Divi).
2. Percorrer a árvore identificando apenas os campos de texto visíveis ao usuário.
3. Bloquear shortcodes, tags dinâmicas, atributos HTML e CSS inline.
4. Enviar apenas as superfícies de texto para o tradutor com contexto.
5. Reinserir o texto traduzido na estrutura original.

Este é o mesmo princípio que nosso motor aplica aos arquivos .po. O guia para traduzir arquivos .po sem quebrar variáveis de código detalha os padrões %s e de placeholders — o equivalente no construtor de páginas são shortcodes e tags dinâmicas.

Um Fluxo de Trabalho Híbrido Que Realmente Funciona

Para a maioria das equipes, a resposta prática é combinar ambas as abordagens.

Passo 1: Traduzir UI de Tema e Plugin via Arquivos .po

Exporte arquivos .pot do seu tema e plugins chave (WooCommerce, Yoast, UI do construtor de páginas). Traduza-os uma vez através de um tradutor na nuvem que respeite o formato .po. Coloque os arquivos .mo compilados em wp-content/languages/. Isso gerencia 80% das strings de interface do seu site com manutenção contínua quase zero.

Passo 2: Escolha um Plugin Multilíngue para Conteúdo Dinâmico

Instale Polylang ou WPML para conteúdo de posts, páginas e produtos. Configure a estrutura de URL (/es/, /fr/) e tags hreflang. Isso lhe dá a infraestrutura para conteúdo de banco de dados por idioma.

Passo 3: Duplicar Seletivamente Seus Modelos de Construtor de Páginas

Para páginas de destino de alto tráfego, páginas iniciais e conteúdo de marketing essencial, duplique a página em cada idioma e traduza os widgets manualmente. Você obtém controle total do design onde é importante.

Passo 4: Use a Tradução de Strings para Blocos Repetidos

Para seções globais, modelos reutilizáveis e CTAs de rodapé que aparecem em todas as páginas, use o recurso de tradução de strings do seu plugin multilíngue. Atualize em um só lugar, troque na renderização.

Passo 5: Realize Verificações de Qualidade

O conteúdo traduzido do construtor de páginas deve ser renderizado sem desvios de layout. Idiomas mais longos (alemão, russo) quebram as larguras dos botões. Idiomas mais curtos (chinês, japonês) deixam espaços em branco estranhos. Teste cada modelo por idioma antes de publicar.

Armadilhas Comuns e Como Evitá-las

Algumas armadilhas que aparecem em todo projeto de localização de construtor de páginas.

Texto Alt de Imagem Não Traduzindo

Tanto Elementor quanto Divi armazenam o texto alt por instância de widget, não na Biblioteca de Mídia. Traduzir a imagem original não traduz o texto alt em todos os widgets que a utilizam. Atualize o texto alt em cada página duplicada.

Formulários e Campos Personalizados

Formulários de contato incorporados em widgets de construtores de páginas têm suas próprias strings (rótulos, placeholders, mensagens de validação). Consulte nosso guia sobre como traduzir Gravity Forms e Contact Form 7 para o lado dos formulários.

Widgets e Modelos Globais

Alterações em um modelo global se propagam para todas as páginas que o utilizam, incluindo cópias traduzidas. Isso pode ser útil ou catastrófico dependendo se você deseja conteúdo compartilhado ou separado. Decida explicitamente por modelo.

Expiração do Cache de Tradução

Construtores de páginas armazenam em cache o HTML renderizado agressivamente. Após traduzir, limpe todos os caches, incluindo o cache CSS do Elementor (Elementor > Ferramentas > Regenerar CSS) e o cache CSS estático do Divi.

Juntando Tudo

Traduzir um site construído com Elementor ou Divi não é mais difícil do que traduzir um tema estático — apenas exige o modelo mental correto. Strings de temas e plugins vivem em arquivos .po e viajam via arquivos .mo. O conteúdo do construtor de páginas vive no banco de dados e viaja via plugins multilíngues ou duplicação manual. Confundir os dois caminhos é a fonte mais comum de frustração "por que minhas traduções não estão funcionando".

O fluxo de trabalho que funciona é entediante: arquivos .mo estáticos para tudo que vive no código, plugin multilíngue para conteúdo de páginas e curadoria manual para páginas de destino de alto valor. Nenhuma ferramenta única lida com os três, e quem prometer o contrário está te vendendo algo.

Pronto para traduzir seus arquivos .po de tema e plugin sem quebrar a marcação do widget? Experimente SimplePoTranslate grátis — não é necessário cartão de crédito. Carregue .po, baixe traduções seguras, solte em wp-content/languages/.