Construir WordPress Multilingue à Escala: WPML vs Polylang vs Personalizado — Um Enquadramento de Decisão Real

A maioria dos projetos WordPress multilingues começa da mesma forma: alguém escolhe o WPML ou o Polylang com base num artigo que leu, configura-o numa tarde, publica o site, e seis meses depois o site está com problemas de desempenho, o fluxo de trabalho editorial é um caos, ou há uma lacuna de tradução que ninguém consegue explicar.

Este site funciona em quatro idiomas (EN/PT/ES/FR) com uma abordagem personalizada porque nenhum dos plugins se adequava aos meus requisitos de forma satisfatória. Essa decisão não foi dogmática — foi a terceira opção depois de ter considerado seriamente as outras duas. Aqui está o framework de decisão que utilizo de facto, com base em projetos reais.

As três opções reais

Esqueça por um momento as páginas de marketing de cada plugin. A nível arquitetural existem três escolhas sérias:

1. WPML — premium, completo, pesado. Cada tradução é um post separado ligado ao original.
2. Polylang — núcleo gratuito / Pro pago, mais leve, mesmo modelo de posts separados.
3. Personalizado — desde um array i18n serializado no tema até uma estratégia de meta de post personalizada ou um seletor de idioma baseado em query vars.

O WordPress multisite com multi-domínio ou subdomínio é tecnicamente uma quarta opção, mas é uma abordagem diferente — está a gerir múltiplas instalações do WordPress. Não vou abordá-la aqui; se estiver a essa escala, a questão já não é “WPML ou Polylang”, mas sim “devo dividir isto em sites separados”.

WPML — quando justifica o seu peso

O WPML é a resposta padrão para agências porque cobre o conjunto mais abrangente de casos prontos a usar: posts, páginas, tipos de post personalizados, taxonomias, campos ACF, strings WooCommerce, strings do tema através do módulo String Translation, menus, widgets, biblioteca de média — tudo é traduzível.

Onde funciona bem

• Sites com forte componente editorial com uma equipa de tradução que necessita de um painel de tradução, integração de tradução automática e um fluxo de trabalho claro sobre “o que é novo na fonte e o que ainda precisa de ser traduzido”
• Lojas WooCommerce que vendem em vários idiomas com nomes de produtos, descrições, atributos e preços em diferentes moedas localizados
• Sites construídos com plugins pesados (Elementor, Divi, configurações ACF complexas) — o WPML tem integrações para quase tudo

Onde falha

• Desempenho. O WPML adiciona entre ~30 a 60 consultas extra à base de dados num carregamento de página típico. Numa página inicial que já executa mais de 150 consultas devido ao excesso de plugins, o WPML ultrapassa as 200. É passível de cache, mas no momento em que existem utilizadores com sessão iniciada ou conteúdo baseado em sessão, o impacto faz-se sentir.
• Tamanho da base de dados. Cada tradução é uma linha em wp_posts, cada metadado traduzido é uma linha em wp_postmeta. Um site com 4 idiomas e 500 publicações torna-se um site com 2.000 publicações ao nível da base de dados.
• Conflitos com plugins mais recentes. A abordagem de “Custom XML config” do WPML para indicar quais as strings a traduzir funciona, mas envelhece — cada atualização de plugin pode exigir ajustes de configuração.

Custo: €99/ano para o Multilingual CMS, €199/ano para o Multilingual Agency. Vale a pena num site editorial suficientemente complexo; é excessivo para um site institucional de 4 páginas.

Polylang — mais leve, mesma estrutura

O Polylang utiliza o mesmo modelo conceptual que o WPML — uma publicação por idioma, ligadas entre si — mas a implementação é mais leve e a versão gratuita é genuinamente utilizável em sites sem WooCommerce.

Onde funciona

• Temas personalizados com tipos de publicação personalizados nos quais se tem controlo total sobre o que é traduzido e não se necessita da cobertura abrangente que o WPML oferece
• Sites onde a equipa editorial é pequena e pode prescindir de um painel de tradução dedicado
• Projetos sensíveis ao orçamento nos quais €99/ano para o WPML não é viável; Polylang gratuito + Polylang Pro (€99 pagamento único) é comparável

Onde falha

• WooCommerce. O Polylang para WooCommerce funciona, mas é menos polido do que o WooCommerce Multilingual do WPML. Se a loja for o principal motor do site, isso é relevante.
• Strings do tema. A Tradução de Strings do Polylang Pro é mais manual do que a do WPML. Terá de distribuir o tema com ficheiros .mo completos via load_theme_textdomain ou depender da interface mais lenta do Polylang.
• Construtores de páginas visuais. Existem integrações, mas falham com mais frequência do que as do WPML.

Personalizado — quando nenhum se adequa

O caminho personalizado não é uma abordagem única — é uma categoria de abordagens. As duas que vejo com mais frequência:

Abordagem A: arrays i18n no tema

Para sites onde o conteúdo é altamente estruturado e editorialmente estável — páginas de destino, sites de marketing com um conjunto fixo de secções — defina cada string traduzível como uma chave num array PHP por idioma, acedida através de um helper do estilo t(). O URL recebe um parâmetro de consulta ?lang=xx (ou um prefixo de caminho), e o idioma ativo é determinado uma vez por pedido.

Pontos fortes: zero de sobrecarga de desempenho, sem consultas adicionais à base de dados, traduções com controlo de versões, implementadas como código. Os editores traduzem editando o array (ou através de uma interface de administração personalizada que escreve nele).

Pontos fracos: não se adequa a um blog com publicações adicionadas com frequência, nem a um catálogo WooCommerce de 500 produtos. No momento em que os editores esperam que o painel WP seja a fonte de verdade para as traduções, esta abordagem começa a parecer inadequada.

Abordagem B: estratégia de post meta

Cada publicação possui um conjunto de campos meta por idioma: title_pt, title_en, etc. Um pequeno filtro escolhe o campo correto no momento da renderização com base na locale ativa. Uma publicação, múltiplas traduções, uma única linha em wp_posts.

Pontos fortes: metade das linhas na base de dados em comparação com o WPML/Polylang. Administração mais rápida (sem necessidade de alternar entre traduções de publicações). Permalinks mais limpos se utilizar parâmetros de consulta ou uma reescrita personalizada.

Pontos fracos: o SEO requer geração manual de hreflang (o que faria de qualquer forma num site a sério). A interface editorial necessita de trabalho personalizado — por defeito, o editor do WP apenas mostra um conjunto de campos, não quatro. O ACF ou metaboxes personalizadas resolvem isto, mas acrescentam complexidade.

O quadro de decisão

Deixe de lado as comparações de funcionalidades e coloque quatro questões:

1. Quem está a traduzir?

Agência externa / serviço de tradução que espera um fluxo de trabalho familiar → WPML. Equipa interna bilingue → Polylang ou solução personalizada. Apenas você → uma solução personalizada é suficiente.

2. Quão estruturado é o conteúdo?

Publicações de blog e páginas com variação rica e alterações frequentes → WPML ou Polylang. Site de marketing altamente estruturado com secções estáveis → o i18n personalizado é mais rápido e mais leve.

3. Existe WooCommerce?

Loja multi-idioma com multi-moeda → WPML. Loja multi-idioma com moeda única → o Polylang para WooCommerce é viável. Sem loja → qualquer um dos plugins ou solução personalizada.

4. Qual é o objetivo de desempenho?

LCP abaixo de 1,5s no percentil 75 em dispositivos móveis → a solução personalizada é o único caminho que o atinge consistentemente sem uma cache agressiva no edge. WPML ou Polylang com cache de página completa no edge → 2 a 3s no primeiro pedido, abaixo de 1s na cache.

Considerações de SEO para as três abordagens

O plugin não o dispensa de implementar corretamente o hreflang. Cada página traduzida precisa de tags hreflang recíprocas a apontar para as suas versões irmãs, mais um x-default para o fallback neutro em termos de idioma. O WPML e o Polylang geram-nas automaticamente, mas já vi ambos produzir resultados subtilmente incorretos (um idioma em falta, código de região errado, parâmetros de query duplicados).

Verifique no HTML renderizado, não nas definições do plugin. Utilize o relatório “Segmentação Internacional” da Google Search Console para detetar erros em cluster ao longo do tempo.

Os canonicals merecem a mesma atenção: cada página traduzida deve ser auto-canónica (é o URL canónico para essa versão no idioma), em vez de apontar para a versão no idioma original. O WPML e o Polylang fazem isto corretamente por omissão; as abordagens personalizadas requerem trabalho explícito.

O que faço na prática

Em projetos de agência, a opção predefinida é o WPML — as expectativas de fluxo de trabalho dos clientes de agência e dos serviços de tradução alinham-se com a forma como este se apresenta.

Em plataformas corporativas com arquitetura personalizada, Polylang ou solução personalizada — dependendo de a equipa editorial necessitar de uma interface de tradução por publicação.

Em sites de marketing com conteúdo altamente estruturado (como este), i18n personalizado via array PHP, servido através de ?lang=xx. Zero consultas à base de dados para traduções, com controlo de versões, implementado como código. Contrapartida: editar requer modificar um ficheiro, não o painel de administração do WP.

Nenhuma destas escolhas é permanente. Os caminhos de migração entre elas são bem conhecidos: WPML → Polylang é direto, Polylang → personalizado é mecânico, e personalizado → qualquer um dos plugins é o mais simples de todos.

O que não quer é a migração para fora de uma configuração que estava errada desde o início porque ninguém fez as quatro perguntas acima.