Guia Completo de Tradução Multilíngue para Sites WordPress

Traduzir um site WordPress é um processo complexo que exige planejamento cuidadoso e execução precisa. Criamos este guia completo com base em nossa vasta experiência na tradução de sites, usando o plugin Gato AI Translations for Polylang.

Este guia orienta você em tudo o que precisa saber: desde os preparativos iniciais e a configuração, passando pelo processo de tradução em si, até a validação e a resolução de problemas. Siga este guia para garantir uma experiência de tradução tranquila.

​

Instalar e Configurar o Polylang

Gato AI Translations for Polylang requer que o Polylang esteja instalado e ativado. Polylang é o framework multilíngue que gerencia seus idiomas e relacionamentos de tradução.

Após a instalação, você precisará configurar o Polylang com seus idiomas:

1. Vá para Languages no menu de administração do WordPress
2. Adicione seu idioma padrão (o idioma do seu conteúdo existente)
3. Adicione todos os idiomas de destino para os quais deseja traduzir

​

Auditar e Corrigir o Conteúdo de Origem Primeiro

Antes de começar a traduzir, é essencial garantir que seu conteúdo de origem esteja em perfeito estado. Qualquer problema no seu conteúdo original será replicado em todas as traduções, o que significa que você precisará corrigir o mesmo problema várias vezes (uma vez para cada idioma).

Lista de verificação de auditoria de conteúdo:

1. Verificar links quebrados

   • Use um plugin como o Broken Link Checker para identificar links internos e externos quebrados
   • Corrija todos os links quebrados antes de traduzir
   • Verifique se os links internos apontam para os posts/páginas corretos

2. Verificar se todas as imagens existem e estão otimizadas

   • Verifique se todas as imagens carregam corretamente
   • Certifique-se de que as imagens tenham texto alt adequado para acessibilidade e SEO
   • Verifique se os tamanhos dos arquivos de imagem são razoáveis (não muito grandes)
   • Remova imagens de placeholder ou referências a imagens quebradas

3. Revisar formatação e estilo

   • Verifique se a formatação do texto é consistente
   • Confirme que os títulos estão estruturados corretamente (H1, H2, H3, etc.)
   • Certifique-se de que listas, tabelas e outros conteúdos estruturados são exibidos corretamente
   • Teste se o estilo personalizado e o CSS funcionam conforme esperado

4. Validar a estrutura do conteúdo

   • Certifique-se do uso adequado de blocos Gutenberg ou elementos de page builder
   • Verifique se os custom post types e taxonomias estão configurados corretamente
   • Confirme que os metadados (custom fields, campos ACF, etc.) estão completos

5. Verificar conteúdo de placeholder

   • Remova qualquer texto "Lorem ipsum" ou placeholder
   • Substitua qualquer conteúdo temporário pelas versões finais
   • Certifique-se de que todo o conteúdo está pronto para publicação

6. Considerações de SEO

   • Verifique se os meta títulos e descrições estão definidos
   • Confirme que as URLs são amigáveis para SEO
   • Certifique-se do uso adequado de títulos para a estrutura de SEO

​

Configurar a Substituição de Links Internos

Ao traduzir conteúdo, os links internos precisam ser atualizados para apontar para as versões traduzidas. Gato AI Translations for Polylang pode fazer isso automaticamente para você.

O plugin permite que você configure quais tipos de links internos devem ser substituídos:

• Custom Posts: links para outros posts, páginas, custom post types, etc.
• Media: links para itens de mídia (imagens, vídeos, etc.)
• Tags: links para páginas de arquivo de tags
• Categories: links para páginas de arquivo de categorias
• Users: links para páginas de autor

Como configurar:

1. Vá para a página de Configurações, em Plugin Configuration > Internal Links Replacement
2. Habilite apenas os tipos de link que você realmente usa no seu conteúdo
3. Salve suas configurações

​

Verificar se Todos os Links Usam URLs Corretas

Para que o recurso de substituição de links internos funcione corretamente, todos os links no seu conteúdo devem usar o formato de URL adequado. Isso se aplica a links em:

• Conteúdo de post/página (blocos Gutenberg, HTML, etc.)
• Widgets e meta fields do Elementor
• Elementos e meta fields do Bricks builder
• Custom fields e metadados

Requisitos de URL:

1. URLs devem incluir o domínio completo

   • ✅ Correto: https://www.meusite.com/hello-world/
   • ❌ Incorreto: /hello-world/ (URL relativa)
   • ❌ Incorreto: hello-world/ (sem domínio ou protocolo)

2. URLs devem apontar para o slug atual

   • Se você alterou o slug de um post, atualize todos os links para usar o novo slug
   • O WordPress precisa conseguir recuperar o post a partir da URL
   • Slugs antigos que redirecionam não funcionarão para substituição de links

3. URLs devem usar o domínio correto (sem redirecionamentos)

   • ✅ Correto: https://www.meusite.com/hello-world/
   • ❌ Incorreto: https://meusite.com/hello-world/ (se seu site usa www)
   • O plugin precisa do domínio exato para corresponder e substituir links corretamente

​

Escolher o Status Rascunho ou Publicado

Quando as traduções são criadas, você precisa decidir se elas devem ser publicadas imediatamente ou salvas como rascunhos para revisão primeiro.

Por padrão, as traduções são salvas como rascunhos. Para que as traduções sejam publicadas imediatamente, vá para a página de Configurações, em Plugin Configuration > General Configuration, e defina a opção Status when translated como Publish ou Same as origin post (se o post de origem já estiver publicado).

​

Suporte a Idiomas da Direita para a Esquerda (RTL)

Se você estiver traduzindo para idiomas da direita para a esquerda como hebraico, árabe, farsi ou urdu, precisa garantir que seu tema suporte adequadamente layouts RTL.

O que o RTL afeta:

Idiomas RTL requerem mais do que apenas mudanças na direção do texto. Seu tema precisa lidar com:

• Direção do layout: os elementos devem fluir da direita para a esquerda
• Alinhamento de texto: o texto deve ser alinhado à direita por padrão
• Ajustes de espaçamento: margin-left deve se tornar margin-right, padding-left deve se tornar padding-right, etc.
• Navegação: menus e navegação devem fluir em RTL
• Formulários: campos de entrada e botões devem se alinhar corretamente
• Ícones e imagens: podem precisar de espelhamento ou reposicionamento

O que já é tratado:

• Polylang define automaticamente a direção correta do idioma (atributo dir="rtl")
• A tradução de conteúdo funciona de forma idêntica para idiomas RTL e LTR
• Gato AI Translations traduz conteúdo corretamente independentemente da direção do texto

O que você precisa verificar:

1. Suporte RTL do tema: teste seu tema com um idioma RTL para ver se ele o lida corretamente

   • Muitos temas modernos incluem folhas de estilo RTL
   • Verifique a documentação do seu tema para obter informações sobre suporte RTL
   • Procure arquivos rtl.css ou similares no seu tema

2. CSS personalizado: revise qualquer CSS personalizado que você tenha adicionado

   • Valores de esquerda/direita fixos podem precisar de ajustes
   • Considere usar propriedades lógicas (margin-inline-start em vez de margin-left)

3. Compatibilidade com page builders: se estiver usando Elementor, Bricks ou outros page builders

   • Verifique se eles suportam layouts RTL
   • Teste os layouts no modo RTL antes de traduzir

Se o seu tema não suporta bem RTL, pode ser necessário mudar para um tema compatível com RTL, adicionar CSS RTL personalizado ou usar um plugin que adicione suporte RTL.

​

Identificar o Conteúdo de Plugins de Terceiros para Traduzir

Muitos plugins WordPress criam seus próprios Custom Post Types (CPTs) para armazenar conteúdo (por exemplo: produtos WooCommerce, eventos do Events Calendar, cursos do LearnDash, etc.).

Antes de traduzir, você precisa:

1. Identificar quais CPTs contêm conteúdo que precisa ser traduzido

   • Revise seus plugins ativos e seus CPTs
   • Determine quais precisam de tradução (nem todos precisam)

2. Garantir que os CPTs e taxonomias relevantes sejam traduzíveis

   • Vá para Languages > Settings > Custom post types and Taxonomies do Polylang
   • Habilite a tradução para os CPTs e taxonomias relevantes

​

Criar Automaticamente Entradas de Tradução para CPTs

Se um CPT depende do método wp_insert_post para criar entradas, você pode ir para a página de Configurações, em Plugin Configuration > General Configuration, e habilitar a opção Automatic creation of translation entries para esse CPT, para que o plugin crie as entradas de tradução automaticamente.

​

Verificar se Seu Plugin de SEO é Suportado

Metadados de SEO (meta títulos, descrições, tags Open Graph, etc.) são cruciais para SEO multilíngue. Gato AI Translations for Polylang inclui suporte integrado para os plugins de SEO mais populares, traduzindo automaticamente todos os metadados relacionados a SEO.

O plugin suporta 8 principais plugins de SEO:

1. All in One SEO
2. Rank Math
3. SEO Simple Pack
4. SEOPress
5. Slim SEO
6. The SEO Framework
7. WP Meta SEO
8. Yoast SEO

Se você estiver usando um plugin de SEO que não está listado acima, deve indicar quais meta keys sincronizar e traduzir, correspondentes ao plugin de SEO que você está usando. Qualquer plugin que armazene seus metadados na tabela wp_postmeta é suportado.

​

Escolher Seu Provedor e Modelo de IA

A qualidade das suas traduções depende do serviço de IA e do modelo que você escolher.

Serviços modernos de IA (como ChatGPT, Claude e Gemini) produzem traduções significativamente melhores do que serviços legados (Google Translate ou DeepL) porque entendem melhor contexto, tom e nuances; preservam corretamente a estrutura HTML e a formatação; não traduzem URLs ou links relativos incorretamente; mantêm o estilo de escrita e a voz nas traduções; e lidam melhor com termos técnicos e linguagem específica do domínio.

Você pode escolher entre os seguintes serviços de IA:

• ChatGPT (OpenAI)
• Claude (Anthropic)
• DeepSeek
• Gemini (Google)
• Mistral AI
• OpenRouter (agregador de LLM que fornece acesso a todos os principais modelos, incluindo Grok e Llama)
• LLM auto-hospedado (hospedado em seu próprio servidor, por exemplo via Ollama)

Recomendamos usar as versões mais recentes dos modelos disponíveis (por exemplo: ChatGPT 5.2 em vez de 5.0), pois os modelos mais novos fornecem consistentemente melhor qualidade de tradução.

Você pode usar o OpenRouter para acessar os modelos de IA mais recentes assim que forem lançados.

​

Considerar Personalizar Seu Prompt de Tradução com IA

O prompt de tradução padrão funciona bem para a maioria dos conteúdos, mas personalizá-lo pode melhorar a qualidade da tradução para o seu caso de uso específico.

Exemplo:

Um blog de viagens pode personalizar seu prompt adicionando o seguinte:

Translate to a natural, flowing, easy-to-read, casual blog-style language. Keep original content structure, meaning, and styling (but do adjust sentence structure and style to be relevant to the target language).
 
Lightly improve boring parts - Add curiosity triggers, light humor, and light slang (as fits the target language), like a human travel blogger would write.Copy

Você pode modificar o prompt padrão ou criar vários prompts de IA personalizados e selecionar qual usar nas Configurações:

​

Auditar Seus Blocos Gutenberg

Antes de traduzir, você precisa identificar quais blocos está usando e garantir que sejam suportados para tradução.

Blocos Gutenberg suportados nativamente:

• Todos os blocos core do WordPress: Paragraph, Heading, List, Quote, Image, Gallery, etc.
• Blocos de terceiros: blocos dos plugins Yoast SEO, GenerateBlocks, Kadence, Greenshift, etc.

Se você estiver usando um bloco não suportado que contém strings que precisam ser traduzidas, você pode:

• Adicionar uma integração para traduzir o bloco, ou
• Substituí-lo por um bloco suportado (por exemplo, substituir um bloco de depoimento personalizado por uma alternativa suportada).

Observação: há blocos que não podem ser traduzidos.

Se você precisar substituir um bloco não suportado, vai querer encontrar todos os posts que o utilizam. Confira o tutorial sobre como encontrar posts que contêm um determinado bloco para métodos de identificar onde blocos específicos são usados.

​

Auditar Seus Widgets do Elementor

Se você estiver usando o page builder Elementor, precisa auditar quais widgets está usando e garantir que sejam suportados para tradução. O processo é semelhante à auditoria de blocos Gutenberg, mas específico para widgets do Elementor.

Todos os widgets core do Elementor são suportados nativamente.

Se você tiver widgets não suportados:

• Adicione uma integração para traduzir o widget, ou
• Substitua-o por um widget suportado

​

Auditar Seus Elementos do Bricks

Se você estiver usando o page builder Bricks, precisa auditar quais elementos está usando e garantir que sejam suportados para tradução. O processo é semelhante à auditoria de blocos Gutenberg, mas específico para elementos do Bricks.

Todos os elementos core do Bricks são suportados nativamente.

Se você tiver elementos não suportados:

• Adicione uma integração para traduzir o elemento, ou
• Substitua-o por um elemento suportado

​

Lidar com Imagens que Contêm Texto

Um erro comum ao traduzir sites é esquecer que imagens podem conter texto que pode precisar ser traduzido.

Quando você traduz um post, as imagens são copiadas para a versão traduzida, e os metadados da imagem (título, texto alt, legenda) são traduzidos, mas qualquer texto dentro dessas imagens permanece no idioma original.

Para auditar suas imagens, a maneira mais fácil é alternar a Biblioteca de Mídia do WordPress para o layout de Grade — isso permite que você escaneie visualmente todas as suas imagens de uma vez e identifique rapidamente aquelas que contêm texto incorporado no idioma errado.

Por exemplo, esta imagem contém texto em hebraico, tornando-a inadequada para outros idiomas.

Suas opções:

1. Manter o texto incorporado (se o idioma ainda puder ser compreendido em geral)

   • Adequado quando o texto está em um idioma amplamente compreendido ou usa símbolos/números universais
   • Nenhum trabalho adicional necessário

2. Remover o texto das imagens

   • Use imagens sem texto incorporado

3. Usar sobreposições de texto em vez de texto incorporado

   • Use imagens sem texto incorporado
   • Sobreponha texto (usando blocos Gutenberg, widgets do Elementor, elementos do Bricks ou CSS) que será traduzido automaticamente

4. Criar versões traduzidas das imagens

   • Crie arquivos de imagem separados para cada idioma
   • Substitua manualmente as imagens nos posts traduzidos

​

Lidar com a Tradução de Dados Adicionais de Usuário

O Polylang pode lidar com o campo de biografia para perfis de usuário do WordPress, mas se você tiver dados adicionais de usuário armazenados em custom fields (via ACF, Meta Box ou outros meios), precisará de uma abordagem especial.

Se você tiver dados de usuário que precisam de tradução (por exemplo, cargos, qualificações, descrições, etc.), precisará criar campos separados para cada idioma.

1. Criar campos separados para cada idioma

   • Usando ACF ou Meta Box, crie campos como:
     • Qualification EN
     • Qualification FR
     • Qualification DE
     • etc.

2. Atualizar seu tema para exibir o campo correto

   • Modifique os templates do seu tema para verificar o idioma atual
   • Exiba o campo apropriado com base no idioma ativo
   • Exemplo de código PHP:

     $current_lang = pll_current_language();
     $qualification = get_field("qualification_{$current_lang}", 'user_' . $user_id);
     echo $qualification;Copy

3. Preencher campos manualmente

   • Após traduzir o conteúdo, atualize manualmente os campos do perfil de usuário

​

Ignorar a Tradução de Termos que Não Devem Ser Traduzidos

Alguns termos nunca devem ser traduzidos — nomes de marcas, nomes próprios, termos técnicos ou terminologia específica do domínio.

Você pode ignorar a tradução desses termos adicionando instruções ao seu prompt personalizado, por exemplo:

Do not translate the following types of terms:
- Hotel names (e.g., "Grand Hotel", "Beach Resort")
- Restaurant names
- Brand names
- Technical acronyms (API, SEO, CMS, etc.)
 
Keep these terms exactly as they appear in the original text.Copy

​

Evitar Tags Duplicadas Entre Idiomas

Nosso conteúdo pode ter tags que representam o mesmo conceito em dois idiomas diferentes. Quando essas tags são traduzidas, elas podem criar duplicatas ou conflitos.

Por exemplo, se você tem um site em chinês sendo traduzido para o inglês, e você tem tanto a tag 布宜诺斯艾利斯 (Buenos Aires em chinês) quanto a tag Buenos Aires em inglês, ao traduzir para o inglês, ambas as tags se tornam buenos-aires. Isso cria uma situação de tag duplicada.

Como corrigir antes de traduzir:

1. Auditar suas tags

   • Revise todas as tags no seu idioma de origem
   • Identifique tags que podem ser duplicatas de tags em outros idiomas
   • Procure tags que representam o mesmo conceito mas em idiomas diferentes

2. Consolidar tags

   • Escolha uma versão de idioma para manter (normalmente seu idioma de origem)
   • Mescle ou remova tags duplicadas
   • Atualize os posts para usar a tag consolidada

3. Limpar antes de traduzir

   • Certifique-se de que seu conteúdo de origem tenha apenas tags no idioma de origem
   • Remova quaisquer tags em idiomas de destino do conteúdo de origem
   • Isso evita conflitos durante a tradução

​

Evitar Nomes de Localidades Duplicados Entre Idiomas

Se o seu conteúdo usa títulos que misturam scripts, você pode ver este padrão: o título começa com um nome de lugar local, depois o mesmo nome em letras latinas entre parênteses, e então o restante da linha.

Padrão de origem típico (exemplo):

• Origem (por exemplo, em hebraico): פוקט (Pouket) - מדריך לאי היפה — nome local, depois uma grafia inglesa ou internacional entre parênteses, depois o subtítulo.
• Traduzido (por exemplo, para o inglês): Pouket (Pouket) - beautiful island guide.

Após a tradução, o título já está em um idioma e script, então a renderização literal do modelo repete o mesmo nome de lugar duas vezes (por exemplo, Pouket (Pouket)).

Solução: refinar o prompt de tradução

Personalize seu prompt para que o modelo normalize aberturas redundantes "Nome (MesmoNome)" quando o conteúdo entre parênteses não adiciona nenhuma informação nova. Por exemplo, adicione instruções como:

If a heading begins with a place name followed by the same translated name in parentheses, remove the duplicate and keep one natural version. Do not remove the parenthesis if the text inside uses a different script, a different spelling, or includes additional descriptive information.Copy

​

Fique Atento aos Slugs de Tags/Categorias

Se seus slugs de tags ou categorias já estão no idioma de destino, você pode assumir que não há nada para traduzir.

Isso geralmente está bem — mas há um problema com o Polylang free (não Pro).

Com o Polylang Pro, termos traduzidos podem reutilizar o mesmo slug entre idiomas. Com a versão gratuita, o WordPress impõe slugs únicos em geral, então o slug do termo traduzido recebe automaticamente um sufixo -2.

Por exemplo: uma categoria com slug travels_and_attractions em hebraico, quando traduzida para o inglês, torna-se travels_and_attractions-2 em vez de manter o mesmo slug.

Se isso afeta suas URLs ou SEO, você precisará corrigir manualmente os slugs após a tradução ou fazer upgrade para o Polylang Pro para permitir a reutilização de slugs entre idiomas.

​

Certifique-se de que Seus Embeds Estejam em um Idioma Aceitável

Se você estiver incorporando conteúdo de terceiros — como Google Maps, widgets de redes sociais ou outros iframes de plataformas — verifique se o embed é exibido no idioma de destino.

Por exemplo, um embed do Google Maps configurado para hebraico ainda mostrará rótulos em hebraico, nomes de ruas e interface em hebraico mesmo após você ter traduzido o resto da página para o inglês. Nesse caso, pode ser necessário usar um embed independente de idioma.

O mesmo se aplica a qualquer plataforma ou serviço que gere embeds específicos de idioma (por exemplo, capítulos do YouTube, widgets de avaliação, formulários de reserva). Sempre verifique cada embed após a tradução.

​

Certifique-se de que Não Há Estilização Específica de Idioma no Conteúdo de Origem

Conteúdo de post escrito para um idioma específico — especialmente idiomas RTL como hebraico ou árabe — pode incluir atributos inline de direção e idioma aplicados diretamente a elementos HTML. Quando esse conteúdo é traduzido para um idioma diferente, esses estilos fixos se propagam e quebram o layout.

Culpados comuns no conteúdo de origem RTL:

• <div dir="rtl" lang="he"> — força a direção RTL e marca o idioma como hebraico em uma seção inteira
• <p dir="rtl"> — força o alinhamento RTL em parágrafos individuais
• <h2 style="text-align: right;"> — fixa o alinhamento à direita nos títulos

Quando esse conteúdo é traduzido para o inglês (ou qualquer idioma LTR), o texto se torna inglês, mas o layout ainda é renderizado da direita para a esquerda — resultando em títulos desalinhados, fluxo de texto invertido e formatação quebrada.

Antes de traduzir, audite seu conteúdo de origem em busca desses atributos e remova-os. Deixe o tema e as configurações de idioma/locale do WordPress controlar a direção e o alinhamento globalmente, em vez de incorporá-los em blocos de conteúdo individuais.

​

Lidar com Templates do Theme Builder do Elementor

Se você estiver usando o Theme Builder do Elementor para criar templates globais (cabeçalhos, rodapés, templates de post único, templates de arquivo, etc.), é importante entender como esses templates são tratados durante a tradução.

O que é traduzido:

• Menus: os itens de menu são substituídos por versões de menu traduzidas
• Conteúdo dinâmico: conteúdo extraído de posts/páginas é traduzido (já que o conteúdo de origem é traduzido)

O que não é traduzido:

• Texto fixo: qualquer texto adicionado diretamente ao template (não proveniente de conteúdo dinâmico) NÃO é traduzido
• Texto de widgets: texto em widgets como títulos, parágrafos, botões, etc. permanece no idioma de origem
• HTML personalizado: qualquer HTML personalizado ou blocos de código permanecem não traduzidos

Exemplo:

Este template de cabeçalho do Elementor contém texto fixo ("Our Phone Number:"):

Solução:

Projete templates para usar apenas:

• Menus (que são substituídos automaticamente)
• Imagens (que são independentes de idioma)
• Conteúdo dinâmico (que vem de posts traduzidos)
• Evite adicionar qualquer texto, título ou descrição fixos diretamente nos templates

Isso garante que os elementos globais do seu site (cabeçalhos, rodapés, etc.) funcionem corretamente em todos os idiomas.

​

Configurar Advanced Custom Fields (ACF)

Se você estiver usando Advanced Custom Fields (ACF), precisa configurar como cada campo deve ser tratado durante a tradução. Os campos ACF podem conter vários tipos de conteúdo, e cada tipo pode precisar de tratamento diferente.

Na seção Gato Translate, os campos ACF podem ser definidos para uma destas opções:

1. (Do nothing): o campo é ignorado na tradução ou sincronização

2. Translate: o conteúdo do campo é traduzido para o idioma de destino

   • Use para: campos de texto, campos textarea, campos WYSIWYG e qualquer campo contendo texto traduzível

3. Copy: o valor do campo é copiado como está para a tradução (não traduzido)

   • Use para: números, datas, checkboxes, campos verdadeiro/falso e qualquer campo que não deva ser traduzido

4. Translate Reference: o campo referencia outra entidade (post, página, usuário, etc.) e a referência é atualizada para apontar para a versão traduzida

   • Use para: campos Post Object, Page Link, Relationship, User e Taxonomy

Se você estiver usando o Polylang Pro, também deve desabilitar seus recursos de tradução ACF para permitir que Gato AI Translations cuide da tradução.

​

Configurar o Meta Box

Se você estiver usando Meta Box (outro popular plugin de custom fields), o processo de configuração é semelhante ao do ACF. Os campos Meta Box também precisam ser configurados para tradução, cópia ou tradução de referência.

Na seção Gato Translate, os campos Meta Box podem ser definidos para uma destas opções:

1. (Do nothing): o campo é ignorado na tradução ou sincronização
2. Translate: o conteúdo do campo é traduzido
3. Copy: o valor do campo é copiado como está
4. Translate Reference: a referência do campo é atualizada para apontar para a entidade traduzida

Você também deve desabilitar os recursos de tradução Meta Box do Polylang para permitir que Gato AI Translations cuide da tradução.

​

Configurar Campos Meta Personalizados

Além de ACF, Meta Box e plugins de SEO, seu site pode ter outros campos meta personalizados de:

• Código personalizado
• Outros plugins
• Custom fields do WordPress (o metabox básico de Custom Fields)

Esses campos meta precisam ser configurados manualmente nas configurações do plugin.

Identificando meta keys personalizadas:

1. Exportar seu conteúdo

   • Vá para Tools > Export no WordPress
   • Exporte todos os tipos de conteúdo que planeja traduzir
   • Isso cria um arquivo XML com todo o seu conteúdo e metadados

2. Analisar o arquivo de exportação

   • Abra o arquivo XML em um editor de texto
   • Pesquise por tags <wp:postmeta>
   • Liste todas as meta keys únicas

3. Filtrar campos conhecidos

   • Remova campos ACF (tipicamente prefixados com o nome do seu field group)
   • Remova campos Meta Box
   • Remova campos core do WordPress (por exemplo, _edit_last, _wp_old_slug, _thumbnail_id)
   • Remova campos de plugins de SEO (se estiver usando um plugin de SEO suportado)

4. Identificar o que resta

   • Esses são seus campos meta personalizados
   • Determine o que cada campo contém e como deve ser tratado

Determinando necessidades de tradução:

Para cada campo meta personalizado, determine:

• Translate: contém texto traduzível (títulos, descrições, conteúdo)
• Copy: contém dados que não devem ser traduzidos (IDs, números, configurações)
• Translate Reference: contém IDs de entidades que devem apontar para versões traduzidas

Configurando no plugin:

1. Vá para as Configurações, na aba Meta Configuration
2. Escolha a opção de tradução (Translate/Copy/Translate Reference)
3. Adicione os nomes das meta keys personalizadas, usando uma correspondência exata ou um padrão regex

​

Executar o Processo de Tradução

Agora que todos os preparativos estão completos, é hora de executar as traduções.

​

Testar o Processo Primeiro

Antes de mergulhar na tradução de todo o seu site, é crucial testar o processo em pequena escala primeiro. Essa abordagem vai economizar seu tempo e evitar que problemas sejam replicados em todo o seu conteúdo.

Aqui está o fluxo de trabalho de teste recomendado:

1. Comece com um único post e um idioma

   • Escolha um post representativo que inclua vários tipos de conteúdo (texto, imagens, links, etc.)
   • Traduza-o para apenas um idioma de destino que você compreenda bem
   • Valide a tradução em profundidade: verifique cada bloco, cada link, cada imagem e cada parte dos metadados
   • Se você descobrir algum problema (por exemplo, um bloco não foi traduzido, um link não foi substituído, a formatação quebrou), corrija-o antes de prosseguir. O mesmo problema será replicado para todos os idiomas se você não resolver agora.

2. Expanda para mais alguns posts

   • Uma vez que a primeira tradução esteja perfeita, traduza mais 3-5 posts para o mesmo idioma
   • Valide cada um minuciosamente
   • Isso ajuda a identificar padrões ou problemas recorrentes

3. Teste com idiomas adicionais

   • Se você estiver traduzindo para vários idiomas, teste com mais um idioma para garantir que tudo funcione em diferentes pares de idiomas

4. Somente então prossiga com a tradução em massa

   • Uma vez que você esteja confiante de que tudo funciona corretamente, pode prosseguir para traduzir o restante do seu site

Essa abordagem incremental garante que quaisquer problemas de configuração ou de conteúdo sejam detectados cedo, quando são fáceis de corrigir.

​

Ordem de tradução

A ordem em que você traduz diferentes tipos de conteúdo é importante, especialmente quando o conteúdo referencia outro conteúdo.

Traduza o conteúdo nesta ordem específica para evitar problemas de referência:

1. Users

   • Descrições de usuários podem estar incluídas em blocos

2. Taxonomies (Tags/Categories)

   • Tags e categorias (e taxonomias personalizadas) são frequentemente referenciadas por posts, portanto precisam existir antes que os posts sejam traduzidos

3. Media

   • Itens de mídia (imagens, vídeos, documentos) são referenciados por posts como imagens em destaque ou imagens de galeria, portanto traduza-os antes dos posts

4. Custom Post Types

   • Traduza posts, páginas e outros CPTs
   • Importante: se um CPT referencia outro, traduza na ordem inversa de dependência
   • Por exemplo: se os posts usam Reusable Blocks, traduza primeiro os Reusable Blocks e depois os Posts

5. Menus

   • Traduza menus por último, pois eles referenciam posts, páginas e categorias

​

Decidir se traduzir slugs ou não

Traduzir slugs de posts e taxonomias para o idioma de destino é frequentemente desejável para idiomas com script latino (por exemplo, francês, alemão, espanhol): o caminho permanece legível e você pode refletir palavras-chave localizadas na URL.

Para scripts não latinos — hebraico, japonês, chinês e similares — slugs localizados frequentemente se tornam uma bagunça: transliterações estranhas, segmentos muito longos, codificação percentual ou URLs difíceis de compartilhar e comparar. Muitas equipes mantêm slugs em latim (ou no idioma de origem) para esses idiomas e contam com o título traduzido para o nome visível e localizado.

Trate a tradução de slugs como uma política por idioma de destino, não como um simples interruptor liga/desliga para o site inteiro:

1. Divida os idiomas em grupos — por exemplo, "traduzir slugs" para destinos latinos vs "não traduzir slugs" para chinês, japonês, hebraico, etc.
2. Execute lotes de tradução separados — traduza em massa para um grupo com a tradução de slugs habilitada, depois execute outro lote para o outro grupo com a tradução de slugs desabilitada.
3. Configure cada lote via Gato Translate (Custom) (abordado em Como executar traduções abaixo): desabilite opções como Translate custom post slugs? e Translate tag and category slugs? para lotes onde deseja manter os slugs inalterados. Busque uma política por execução (por exemplo, um idioma ou um grupo de idiomas que compartilham a mesma regra) para que as configurações correspondam ao resultado esperado.

Para fluxos de trabalho com scripts ou repetíveis, WP-CLI suporta --translate-slugs=true ou --translate-slugs=false por invocação.

​

Tradução em dois passos

Se você habilitou substituição de links internos ou tradução de referência de entidade, pode precisar traduzir em dois passos:

Passo 1: Traduzir apenas propriedades

1. Configure a tradução para excluir conteúdo e meta, ou seja, traduzir apenas propriedades (título/nome e slug)
2. Execute a tradução

Após executar o primeiro passo, os posts traduzidos serão criados com suas URLs e IDs traduzidos, permitindo que as URLs de links internos e IDs de referências de entidade sejam resolvidos para o idioma de destino.

Passo 2: Traduzir apenas conteúdo e meta

1. Configure a tradução para traduzir apenas conteúdo e meta (ou seja, excluir propriedades)
2. Execute a tradução novamente

Após executar o segundo passo, o conteúdo e meta restantes serão traduzidos, e as URLs de links internos e IDs de referências de entidade serão substituídos pelas versões traduzidas.

​

Como executar traduções

Opção 1: Administração do WordPress (Bulk Actions)

1. Vá para a lista de conteúdo (Posts, Páginas, Mídia, etc.)
2. Selecione os itens que deseja traduzir
3. Escolha Gato Translate no menu suspenso de bulk actions
4. Clique em Aplicar

Alternativa: Gato Translate (Custom)

Para mais controle, use Gato Translate (Custom), que permite substituir as configurações para aquela execução de tradução específica:

Isso abre uma página de configurações personalizada onde você pode fornecer opções específicas para aquela execução de tradução:

Opção 2: WP-CLI (para grandes lotes)

Para sites grandes com centenas ou milhares de itens, WP-CLI é uma alternativa conveniente.

Você pode executar traduções em lote via linha de comando e então executar as traduções em segundo plano enquanto trabalha em outra coisa.

​

Verificar logs de tradução

Quando uma tradução falha (devido à API ficar offline, créditos de API esgotados, etc.) ou produz avisos, você verá um badge de notificação no menu do plugin:

Revise os logs de tradução para entender o que aconteceu:

1. Vá para o item de menu Logs no menu do plugin
2. Revise quaisquer erros ou avisos
3. Corrija quaisquer problemas antes de continuar

​

Reexecutar traduções com falha

Sempre que uma tradução falhar, você pode acionar novamente a tradução apenas dessa entrada e idioma e evitar gastar créditos de API em traduções que foram bem-sucedidas.

Traduções com falha são destacadas com um fundo amarelo no ícone de edição do Polylang:

Você pode filtrar para mostrar apenas entradas com traduções com falha:

Para retraduzer apenas as entradas com falha, use a bulk action Gato Translate (Custom) com a opção Process failed translations only:

​

Validar a Qualidade e a Completude da Tradução

Após traduzir o conteúdo, é crucial validar que as traduções foram bem-sucedidas e de boa qualidade. Não assuma que tudo funcionou perfeitamente — reserve um tempo para verificar.

Validação no editor:

Abra os posts traduzidos no editor do WordPress e verifique:

1. Tradução do conteúdo

   • Todo o texto foi traduzido? (não apenas o título)
   • Todos os blocos/widgets/elementos foram traduzidos?
   • Verifique blocos Gutenberg, widgets do Elementor ou elementos do Bricks
   • Confirme que a formatação foi preservada

2. Campos personalizados

   • Os campos ACF foram traduzidos/copiados/referenciados corretamente?
   • Os campos Meta Box foram tratados adequadamente?
   • Os campos meta personalizados estão configurados corretamente?

3. Metadados de SEO

   • Verifique se os meta títulos foram traduzidos
   • Confirme se as meta descrições foram traduzidas
   • Confirme se as tags Open Graph foram traduzidas
   • Revise quaisquer outros campos do plugin de SEO

4. Mídia

   • As imagens em destaque estão definidas corretamente?
   • As imagens no conteúdo apontam para versões traduzidas (se aplicável)?
   • Os textos alt das imagens foram traduzidos?

5. Links

   • Os links internos apontam para versões traduzidas?
   • Os links externos foram preservados corretamente?
   • Os links de categoria/tag funcionam?

Validação no frontend:

Visualize os posts traduzidos no navegador e verifique:

1. Aparência visual

   • A página parece correta?
   • O layout foi preservado?
   • As imagens estão sendo exibidas corretamente?
   • O estilo está correto?

2. Aplicação de template

   • O template correto está sendo usado?
   • O cabeçalho/rodapé está sendo exibido corretamente?
   • As barras laterais/widgets estão sendo exibidas?
   • O menu está mostrando a versão traduzida?

3. Funcionalidade

   • Todos os links funcionam?
   • Os formulários estão funcionando?
   • Os elementos interativos funcionam?
   • A navegação está correta?

4. Elementos específicos do idioma

   • Para idiomas RTL, o layout está correto?
   • As fontes estão sendo renderizadas corretamente?
   • A direção do texto está correta?

Qualidade da tradução:

A tradução com IA moderna geralmente é muito boa, mas você ainda deve revisar:

1. Idiomas que você entende

   • Leia as traduções nos idiomas que você conhece
   • Verifique precisão, tom e estilo
   • Confirme que os termos técnicos estão corretos
   • Certifique-se de que a voz da marca está sendo mantida

2. Idiomas que você não entende

   • Para idiomas que você não fala, considere contratar um falante nativo para revisar
   • Isso é especialmente importante para idiomas muito diferentes do seu (por exemplo, inglês para coreano, chinês, árabe)
   • Mesmo uma revisão rápida pode detectar problemas importantes
   • A revisão profissional é recomendada para conteúdo importante

3. Conteúdo específico do domínio

   • Conteúdo técnico pode precisar de revisão especializada
   • Conteúdo jurídico/médico deve ser revisado por profissionais
   • Conteúdo de marketing pode precisar de ajustes na voz da marca

​

Reparar Blocos com "Conteúdo Inválido"

Ao traduzir grandes blocos de HTML que contêm muitas tags e atributos, os serviços de IA podem às vezes retornar uma resposta que quebra a saída do bloco.

Por exemplo, ao traduzir um bloco core/paragraph que contém um blob HTML muito grande usando ChatGPT 5.0 mini, como este:

<!-- wp:paragraph -->
<p>
  Pédagogie: 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><strong><br></strong>Support : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Coûts : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Débouchés : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark>
</p>
<!-- /wp:paragraph -->Copy

...a resposta pode introduzir uma tag <mark> extra que não estava presente no conteúdo original:

<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★
+<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">Copy

Ao editar o post no editor do WordPress, esse bloco pode não ser renderizado e em vez disso exibir a mensagem "Block contains unexpected or invalid content":

Clicar em Attempt recovery provavelmente resolverá o problema.

​

Solucionar Erros de Dados Corrompidos

Ocasionalmente, você pode encontrar erros durante a tradução porque seu conteúdo contém dados corrompidos ou obsoletos. Isso geralmente acontece quando:

• Um tipo de post anteriormente suportava um recurso (como posts pai) mas não suporta mais
• O conteúdo referencia entidades que não existem mais
• Inconsistências de banco de dados de migrações ou mudanças de plugins
• Relacionamentos órfãos em custom fields

Entendendo o erro:

Quando você vê um erro como este nos logs:

2025-10-25T03:40:38+00:00 Error [Query "create-missing-translation-media"] Execution with errors: 🔴 Object with ID '26061' (of type 'GenericCustomPost') cannot be loaded. Please check if referencing this ID is stale data (i.e. still stored on the WordPress database, but pointing to a non-existing object) and, if so, remove it or fix it.Copy

Isso significa:

• O conteúdo referencia uma entidade (post, página, mídia, etc.) com ID 26061
• Essa entidade não existe mais no banco de dados
• O plugin não pode traduzir porque não consegue resolver a referência

Como corrigir:

Método 1: Editor do WordPress (mais simples)

1. Abra o post/item que está falhando na tradução
2. Identifique a referência corrompida (verifique custom fields, relacionamentos, etc.)
3. Remova ou corrija a referência
4. Salve o post
5. Tente traduzir novamente

Método 2: Limpeza do banco de dados

Se você não conseguir corrigir pelo editor:

1. Identifique qual campo contém a referência inválida
2. Use uma ferramenta de banco de dados ou plugin para remover os dados obsoletos
3. Tenha cuidado — sempre faça backup antes de fazer alterações no banco de dados

Método 3: Gato GraphQL (avançado)

Como Gato AI Translations for Polylang usa Gato GraphQL por baixo dos panos, você pode executar queries GraphQL para corrigir dados corrompidos de forma programática:

1. Primeiro, recupere os IDs dos itens com problemas usando uma query GraphQL.

2. Depois corrija o problema usando uma mutation. Por exemplo, para remover uma referência pai de um item de mídia:

mutation {
  updateMediaItem( input: { id: 26066, customPostID: null } ) {
    status
    errors {
      __typename
      ...on GenericErrorPayload {
        message
      }
    }
  }
}Copy

Se você não conseguir corrigir:

Se os dados corrompidos não puderem ser limpos, pode ser necessário:

• Recriar o post/item do zero
• Exportar o conteúdo, limpá-lo e reimportá-lo
• Entrar em contato com o suporte para assistência com casos complexos

​

Integrar Entradas Traduzidas na Configuração

Após traduzir seu conteúdo, as entradas traduzidas recém-criadas podem precisar ser integradas à configuração do site.

​

Atualizar ACF Field Groups

ACF Field Groups podem ser atribuídos a posts, páginas, categorias, tags ou outras entidades específicas. Quando você traduz conteúdo, as versões traduzidas também podem precisar ser atribuídas aos mesmos field groups.

Após traduzir, atualize as atribuições dos seus ACF Field Groups para incluir as versões traduzidas:

1. Vá para o item de menu Field Groups no menu do plugin ACF
2. Edite o field group que se aplica a entidades específicas
3. Nas Location Rules, adicione as versões traduzidas
4. Salve o field group

Exemplo:

Um field group se aplica ao post específico "Hello World" no idioma de origem:

Após traduzir o post, as versões traduzidas ("Hola Mundo" em espanhol e "你好世界" em chinês) também devem ser atribuídas ao mesmo field group:

​

É isso!

Você concluiu o processo de tradução. Parabéns! 👏

​

Conclusão

Este guia completo deve ajudá-lo a traduzir com sucesso seu site WordPress. Se você precisar de mais informações, consulte a documentação do Gato AI Translations for Polylang.