De volta em 2021, um cliente de e-commerce alemão veio à Seahawk com um briefing que basicamente dizia: "Precisamos que nossa loja WooCommerce esteja em inglês, francês e polonês. Até março." Era novembro. E o orçamento para tradução humana era, digamos, ambicioso na direção errada. Tínhamos usado a API do Google Translate em alguns projetos antes e o resultado era, honestamente, envergonhador para qualquer coisa além de rótulos de botões. Então eu procurei.
Foi quando me sentei de verdade com o DeepL. Eu tinha visto mencionado em alguns threads de desenvolvedores mas não tinha levado a sério. O maior erro que cometi naquela meia década. Assim que executei as mesmas descrições de produtos através de ambas as APIs e mostrei ao cliente a saída lado a lado, não havia disputa. Entregamos a loja alemã em três idiomas antes do Natal, o cliente adicionou holandês seis meses depois sem esforço, e esse projeto ainda é um que aponto quando pessoas perguntam como se parece uma boa integração de API.
Este post é sobre a realidade prática de integrar DeepL em um site. Não a cópia de marketing. As decisões reais de implementação, o modelo de custo, as armadilhas, e o que eu diria para meu eu do passado antes de começar.
Por Que DeepL Realmente Supera as Alternativas
Vou ser direto: para idiomas europeus, DeepL está em um nível diferente. O modelo foi treinado intensamente no corpus Europarl e outros textos paralelos de alta qualidade, e você sente isso imediatamente na saída para alemão, francês, espanhol, italiano, holandês, polonês e português. A estrutura da sentença parece considerada em vez de apenas trocada palavra por palavra.
A API do Google Translate (v2 e v3) é mais barata e cobre mais idiomas. 133 versus 29 idiomas suportados pelo DeepL até meados de 2024. Se você precisa de suaíli ou bengali, DeepL não é sua resposta. Ponto final. Mas se seu cliente está expandindo pela UE ou para o Japão (DeepL faz japonês notavelmente bem), você estaria fazendo um desserviço a ele usando Google por hábito.
A outra coisa que ninguém fala o bastante: o parâmetro de formalidade do DeepL. Você pode definir formality=more ou formality=less e a API vai ajustar o registro da saída de forma correspondente. Isso importa enormemente para o alemão, onde du/Sie não é uma escolha estilística menor. Uma marca DTC de moda quer um registro diferente de uma empresa B2B SaaS. Tive clientes que notaram essa distinção na sua cópia traduzida sem eu nem apontar.
Entendendo o Modelo de Custo Antes de Se Comprometer
DeepL cobra por caractere traduzido. O plano API gratuito (DeepL API Free) oferece 500.000 caracteres por mês. Isso parece muito até você estar traduzindo um catálogo WooCommerce com 800 produtos e descrições longas.
O plano Pro começa em torno de $6.99/mês para 500.000 caracteres e escala a partir daí. Para a maioria dos projetos de agência que executo, o custo fica em algum lugar entre $15 e $60 por mês dependendo do tamanho do catálogo e frequência de atualização. Compare isso com as taxas de tradução profissional humana (tipicamente £0.10 a £0.18 por palavra no mercado do Reino Unido) e a API se paga dentro das primeiras 200 palavras.
Uma coisa que me queimou no início: tratamento de HTML. DeepL pode receber HTML bruto e vai tentar preservar as tags em vez de traduzi-las. Você passa tag_handling=html na sua requisição. Mas se seu HTML está malformado ou suas descrições de produtos contêm scripts inline (olhando para você, alguns plugins WooCommerce), a saída pode ficar corrompida. Aprendi a higienizar o conteúdo antes de chegar à API, não depois.
Os Dois Caminhos de Integração: WordPress e Builds Customizados
Sites WordPress
Para WordPress, o caminho mais direto que usei é a integração WPML. WPML tem um conector DeepL nativo construído no seu módulo de Translation Management. Você autoriza sua chave API do DeepL nas configurações do WPML, seleciona quais tipos de conteúdo traduzir automaticamente, e ele gerencia a fila. Não é magia, uma etapa de revisão humana ainda vale a pena construir no workflow, mas para um site de 300 páginas economiza semanas.
A alternativa é Polylang Pro com o complemento DeepL. Licenciamento um pouco mais barato, um pouco menos polido no lado de gerenciamento de tradução. Usei Polylang em um site de um grupo de restaurantes franceses no ano passado. Adequado para essa escala. Mas para qualquer coisa com tipos de post customizados e campos ACF, WPML lida melhor com os casos extremos na minha experiência.
Se você está construindo WordPress headless (front-end Gatsby ou Next.js puxando dados do WP via GraphQL), você vai querer chamar a API DeepL diretamente do seu pipeline de build ou de uma função serverless. Não tente fazer um shim através de um plugin nessa arquitetura. Não vai escalar de forma limpa.
Builds Customizados / Não-WordPress
Aqui é que fica interessante. DeepL publica bibliotecas de cliente oficiais para Python, Node.js, PHP, Ruby, .NET e Java. A biblioteca Node.js é sólida. Usei em um projeto Next.js onde cacheávamos traduções em Redis para evitar chamadas de API redundantes em strings repetidas.
Uma chamada Node.js básica fica assim:
`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``
Simples. A verdadeira questão arquitetural é o caching. Você não quer bater a API a cada carregamento de página. Armazene traduções no seu banco de dados ou em uma camada de cache (Redis funciona bem, até mesmo um arquivo JSON simples funciona para sites pequenos). Invalide o cache quando o conteúdo fonte muda. É isso. A maior parte da complexidade fica na lógica de invalidação do cache, não na própria chamada de API.
Tratando Placeholders e Conteúdo Dinâmico
Isso pegou um dos meus desenvolvedores na Seahawk em um projeto SaaS onde as strings da UI continham variáveis como {{user_name}} e {{count}}. Envie aquilo cru para o DeepL e às vezes ele vai traduzir os nomes das variáveis. Não é ideal quando {{nombre_de_usuario}} acaba na sua UI em Espanhol.
A solução: use o tratamento XML do DeepL e envolva seus placeholders em tags de ignore antes de enviar.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
Configure tag_handling=xml e ignore_tags=deepl:ignore nos parâmetros da sua requisição. A API preserva tudo dentro dessas tags. Está documentado na referência da API do DeepL, mas é fácil passar batido na primeira leitura. Me custou umas três horas de debug naquele projeto SaaS. Esperamos que não custe nada para você.
Construindo um Fluxo de Revisão Sensato
Tradução automática não é um botão de publicação. Eu nunca recomendaria enviar a saída do DeepL direto para um site ao vivo sem pelo menos uma passada de um falante nativo, particularmente para qualquer coisa voltada ao cliente. Mas o fluxo não precisa ser doloroso.
Aqui está o que eu configuro para a maioria dos projetos de cliente:
- Execute a tradução inicial através da API do DeepL.
- Envie a saída para uma tabela de tradução em staging (no WPML isso é automático; em builds customizados eu escrevo em uma tabela de tradução no DB com uma coluna de
statuspadrão comopending). - Envie um link para o revisor do cliente no mercado local (muitas vezes a própria equipe local do cliente ou um freelancer do ProZ).
- O revisor edita diretamente no CMS ou em uma interface de revisão simples que eu construo.
- O status muda para
approved, o conteúdo vai ao vivo. - Bloqueie a string para que não seja sobrescrita na próxima sincronização da API.
Esse último passo é importante. Já vi configurações em que uma atualização de conteúdo no idioma de origem dispara uma re-tradução completa e apaga todas as correções humanas. Construa o mecanismo de bloqueio antes de construir qualquer outra coisa.
Considerações de SEO para Sites Multilíngues
Conteúdo traduzido sozinho não vai rankear. Você precisa de tags hreflang no HTML <head> para cada variante de idioma, e elas precisam estar corretas. Uma configuração de hreflang incompatível pode na verdade suprimir suas páginas internacionais nos resultados de busca. Vi isso acontecer com um cliente que tinha um belo site em francês traduzido desaparecido por quatro meses porque alguém errou os códigos de idioma (fr-FR vs fr).
Além de hreflang: URLs traduzidas. O ideal é traduzir também os slugs, não /fr/how-to-cook-pasta mas /fr/comment-cuire-les-pates. DeepL consegue traduzir slugs, mas você vai querer passá-los por um formatador de slug depois (minúsculas, hífens, remover caracteres especiais). WPML faz isso automaticamente. Em builds customizadas, faça manualmente.
E metadados. Títulos de página, meta descriptions, alt text em imagens. Tudo precisa de tratamento de tradução. Passo metadados através de DeepL separadamente no pipeline, não como parte do lote de conteúdo do corpo. Mais fácil de controlar limites de caracteres assim.
Onde DeepL não é Suficiente
Resposta honesta: terminologia específica de marca. DeepL não sabe o que seu cliente chama suas features de produto. Se um cliente de fintech usa "Smart Vault" como nome de produto, DeepL vai traduzir. Toda vez.
A solução é o recurso de glossário do DeepL. Você define pares de termos via API (termo de origem, termo de destino, par de idiomas) e anexa o ID do glossário às suas solicitações de tradução. Esse Smart Vault vira "Smart Vault" em todos os idiomas porque você disse para isso acontecer. Você pode gerenciar glossários programaticamente ou via dashboard do DeepL. Agora eu configuro glossários como parte do kickoff de cada projeto. Leva 20 minutos e previne uma categoria de erros que custaria horas para pegar em revisão.
A outra limitação honesta: cobertura de idiomas do DeepL. 29 idiomas é genuinamente restritivo se seu cliente tem ambições além da Europa e Leste Asiático. Se você precisa de árabe, está olhando para uma abordagem híbrida: DeepL para os idiomas europeus, Google Cloud Translation ou Microsoft Azure Translator para todo o resto, unificado atrás de uma camada de API interna única que roteia por par de idiomas. Incômodo de construir uma vez. Muito conveniente de manter.
FAQ
A API do DeepL é gratuita?
Há um nível gratuito com 500.000 caracteres por mês, o que é generoso para testes e projetos pequenos. O plano gratuito exige um cartão de crédito cadastrado, mas não cobrará você a menos que ultrapasse o limite ou faça upgrade. Para sites em produção com qualquer volume real de tráfego ou conteúdo, você quase certamente desejará um plano pago. Os níveis Pro começam em torno de $6.99/mês e escalam pelo uso de caracteres.
Posso usar DeepL com WordPress sem um plugin?
Tecnicamente sim. Você pode chamar a REST API diretamente de um plugin customizado do WordPress ou do functions.php usando wp_remote_post(). Mas a menos que goste de reinventar a roda, as integrações WPML ou Polylang cuidam da fila de tradução, sincronização de strings e bloqueio de conteúdo para você. Eu só usaria API direta customizada no WordPress se tivesse uma razão arquitetônica muito específica.
Qual é a precisão do DeepL comparada à tradução humana?
Para idiomas europeus, DeepL regularmente fica dentro de alguns pontos percentuais da tradução humana em benchmarks de pontuação BLEU. Falando na prática: adequada para descrições de produtos e strings de UI, não adequada para documentos legais, copy criativo, ou qualquer coisa onde tom e nuance cultural são o ponto todo. Sempre construa uma etapa de revisão humana em seus projetos com clientes.
A tradução do DeepL afeta SEO?
Conteúdo traduzido automaticamente que não foi revisado pode ser marcado como de baixa qualidade pelos mecanismos de busca, particularmente se ler de forma não natural. Google afirmou que não penaliza conteúdo auto-traduzido em si, mas conteúdo fino ou confuso terá desempenho inferior. Minha regra: revise antes de indexar, não depois.
Qual é a melhor forma de lidar com atualizações de tradução quando o conteúdo-fonte muda?
Rastreie um hash de conteúdo (MD5 da string de origem é adequado) ao lado de cada tradução no seu banco de dados. Quando o conteúdo-fonte é atualizado, o hash muda, o que marca a tradução como desatualizada. Seu pipeline então retraduz apenas as strings alteradas em vez de toda a página. Isso mantém os custos da API baixos e evita agitação desnecessária em strings que já foram revisadas por humanos.
---
A API DeepL é uma daquelas ferramentas que genuinamente mudou como eu dimensiono projetos multilíngues. Não porque remove a necessidade de julgamento humano, mas porque desloca o trabalho de tradução tedente de primeira versão para revisão editorial significativa. Esse é um melhor uso do tempo de todos, incluindo o orçamento do seu cliente. Configure com cuidado, faça cache agressivamente, construa a etapa de revisão desde o primeiro dia, e ela vai servir você bem.
Leitura relacionada: Pesquisa de palavras-chave com IA em 2026: o que é, por que tradicional, SEO técnico e busca com IA.