A armadilha da tradução: o que a criação de um site multilíngue me ensinou sobre respeito
Achei que adicionar cinco idiomas ao meu portfólio seria um desafio técnico. No fim das contas, foi uma lição de empatia.
Crescendo no Brasil, aprendi inglês assistindo séries americanas com legendas. Lembro das traduções estranhas. "Cool" virava "legal." Gírias eram achatadas em português de livro didático. As palavras estavam corretas. A sensação estava errada.
Vinte anos depois, criei um script de tradução para meu portfólio. Em menos de uma hora, ele converteu "Next.js dashboard" em "painel do Next.js."
Fiz uma careta. Nenhum desenvolvedor brasileiro fala "painel." A gente só diz dashboard.
Eu estava fazendo a mesma coisa que aqueles tradutores de legenda faziam. Convertendo palavras em vez de adaptar significado.
Por que isso importa
Pesquisas mostram que 75% dos usuários de internet preferem conteúdo em seu idioma nativo, mesmo quando entendem inglês. Não é sobre compreensão. É sobre confiança. A sensação de "isso foi feito para alguém como eu."
Para um portfólio, essa sensação importa. Quando um gerente de contratação em Tóquio chega no meu site, quero que ele avalie meu trabalho, não que traduza na cabeça. Quando alguém em Paris lê sobre meus projetos, quero que pense nas ideias, não no idioma.
Um portfólio só em inglês envia uma mensagem: "Isso é para falantes de inglês primeiro, todo mundo depois." Eu queria inverter isso.
O que a comunidade de localização me ensinou
Aquele erro do "dashboard" me jogou na toca do coelho da localização. Li posts de engenheiros de i18n, fuçei discussões no GitHub e estudei como grandes empresas de tecnologia lidam com tradução.
O padrão era consistente em todas as fontes.
Audiências técnicas compartilham um vocabulário que atravessa fronteiras. Desenvolvedores brasileiros dizem "data pipeline," não "canalização de dados." Engenheiros japoneses mantêm "TypeScript" como TypeScript. Marketers franceses usam "growth marketing," não o equivalente do dicionário.
Esses termos foram aprendidos em inglês. São discutidos em inglês. Traduzi-los cria confusão, não clareza.
Meu script estava minucioso demais. Estava traduzindo coisas que deveriam ficar em inglês.
Tradução versus localização
Essa distinção se tornou o insight central do projeto.
Tradução converte palavras. Localização adapta experiências.
Um site traduzido diz "painel de controle" porque o dicionário diz. Um site localizado diz "dashboard" porque é isso que desenvolvedores brasileiros realmente dizem.
Um site traduzido converte cada termo. Um site localizado sabe quando parar. Um desenvolvedor no Japão precisa de navegação em japonês, mas espera termos técnicos em inglês. Esse equilíbrio faz o conteúdo parecer nativo em vez de traduzido.
Reescrevi minha abordagem. Rótulos de navegação traduzem. Nomes de produtos ficam em inglês. Termos técnicos ficam em inglês. Conteúdo explicativo traduz naturalmente.
As regras que criei
Depois de corrigir erros suficientes, padrões emergiram. Documentei todos:
Manter em inglês: Nomes de produtos como Next.js, TypeScript, Claude. Termos da indústria como dashboard, data pipeline, growth marketing, e-commerce. Seções de habilidades e nomes de certificações.
Traduzir: Itens de navegação, rótulos de formulários, conteúdo narrativo, títulos de seção.
Adaptações específicas por idioma:
Para português, usar "dashboard" não "painel," usar "template" não "modelo." Desenvolvedores brasileiros aprenderam esses termos em inglês e os usam diariamente.
Para espanhol, usar "dashboard" não "cuadros de mando," usar "marketers" não "vendedores," usar "data pipelines" não "canalizaciones de datos."
Para japonês, manter nomes de produtos em inglês (Next.js, não ネクストジェイエス). Katakana funciona para palavras emprestadas comuns como ダッシュボード (dashboard).
Para francês, usar "dashboard" não "tableaux de bord," usar "marketers" não "spécialistes du marketing."
Essas regras vivem na documentação do meu projeto agora. Toda vez que traduzo conteúdo, confiro com elas.
Quando a ficha caiu
A primeira vez que carreguei meu site em japonês, algo mudou.
Não falo japonês. Não consigo ler além de alguns caracteres. Mas lá estava: meu portfólio, meus projetos, em um idioma que não conheço.
A navegação dizia "プロジェクト" (projetos). O corpo do texto fluía em japonês. Mas "Next.js" continuou "Next.js." "TypeScript" continuou "TypeScript." O equilíbrio parecia certo.
Conteúdo escrito para cada audiência, não traduzido para eles. Essa distinção captura tudo que aprendi.
O custo de não fazer isso
A maioria dos portfólios que vejo é só em inglês. Tudo bem. Inglês é a língua franca da tecnologia.
Mas quando alguém chega no seu site e tem que fazer tradução mental, você adicionou atrito. Podem sair mais rápido. Podem entender menos. Podem confiar menos. Essa carga cognitiva é invisível mas real.
Um site multilíngue diz: "Eu pensei em você. Fiz isso para você. Seu contexto importa."
Em uma área onde todo portfólio usa os mesmos frameworks e mostra projetos parecidos, essa consideração se destaca.
A parte técnica, brevemente
O sistema usa next-intl para roteamento e a API do DeepL para tradução inicial. Escrevi scripts que processam arquivos MDX, preservam frontmatter e aplicam regras de localização. O pipeline inteiro roda em menos de 30 segundos.
Mas tradução automática é só o primeiro passo. Depois que o DeepL gera a versão inicial, peço ao Claude para revisar cada tradução contra as melhores práticas de localização. O Claude identifica termos que devem ficar em inglês, corrige frases estranhas e garante que o vocabulário técnico corresponda ao que desenvolvedores realmente usam em cada idioma.
Essa combinação de velocidade e qualidade importa. Se localização levasse horas de trabalho manual, eu pararia de fazer.
Para detalhes técnicos, veja a página do projeto. Este post é sobre a jornada.
O que aprendi
Comecei pensando em alcance. Mais idiomas, mais visitantes, melhor SEO. Essas coisas são verdade, mas não são o ponto.
A verdadeira lição foi empatia. Construir para uma audiência global me forçou a pensar em pessoas cujo contexto não compartilho.
Para português, eu tinha vantagem. Sou falante nativo. Consigo identificar estranheza na hora. Para japonês e francês, tive que confiar no que a comunidade de localização documentou. O que posts de blog e guias de estilo dizem sobre como audiências técnicas realmente se comunicam.
Essa dependência de conhecimento externo é humilhante. Você não pode assumir que seus padrões são universais. Precisa encontrar as pessoas onde elas estão.
Um convite permanente
As traduções neste site não são perfeitas. Tradução automática é um ponto de partida. Falantes nativos captam nuances que algoritmos perdem.
Se você ler algo em português, espanhol, japonês ou francês que soe estranho, me avise pelo formulário de contato. Agradeço.
Localização nunca está terminada. É uma conversa contínua entre quem constrói e a audiência. Construir para uma audiência global significa estar aberto a feedback de pessoas que conhecem seu contexto melhor do que você jamais conhecerá.