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.DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.
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.formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.
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.HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.
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.WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.
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.official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.
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' `` 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.{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.
A solução: use o tratamento XML do DeepL e envolva seus placeholders em tags de ignore antes de enviar.XML handling and wrap your placeholders in ignore tags before sending.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <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ê.tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.
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 status padrão como pending).
translationsDB table with astatuscolumn defaulting topending). - 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).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.
approved, content goes live. - 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).hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( 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./fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.
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.glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.
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.wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.
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.