Consultoria de Internacionalização: Corrija o Que Está Quebrando, Planeje o Próximo Passo
Você já sabe que i18n é difícil. Eu já vi os sintomas: layouts RTL que quebram, texto em alemão transbordando botões, respostas de API no idioma errado e traduções que perdem a sincronia semanas após o lançamento. Eu não vendo soluções mágicas. Eu ajudo você a desembaraçar a confusão específica em que sua equipe se encontra — e a criar sistemas que não vão quebrar do mesmo jeito duas vezes.
"A gente devia ter planejado isso antes"
O custo de arquitetura que você está pagando agora
Você lançou em inglês. Funcionou. Depois adicionou francês "só para a landing page". Agora você está aqui porque:
Seu codebase tem verificações de lang= espalhadas por 47 arquivos
Gerentes de produto perguntam "dá para fazer teste A/B de copy?" e a engenharia responde "não sem reescrever tudo"
Você tem três fluxos de trabalho de tradução diferentes e nenhum deles funciona de forma confiável
O que já vi quebrar:
- Times que gastaram mais de 6 meses adaptando i18n em um app Next.js porque as strings estavam hardcoded nos componentes
- Arquivos de tradução perdendo a sincronia porque os desenvolvedores não sabem qual arquivo atualizar
- Períodos de congelamento de localização antes dos lançamentos porque ninguém confia no pipeline de tradução
- Resistência a alterar qualquer conteúdo traduzido porque o fluxo de trabalho é muito penoso
No que eu ajudo:
- Estratégias de refatoração que permitem adotar i18n de forma incremental (eu não exijo "pare tudo e reescreva")
- Planejamento do processo para manter as traduções em sincronia sem bloquear o desenvolvimento
- Revisões de arquitetura para identificar onde sua abordagem atual vai quebrar com mais de 10 idiomas
i18n é arquitetura, não uma funcionalidade. Tentar adicionar depois é como decidir que sua casa precisa de um porão depois que você já construiu.
Eu ajudo você a cavar esse porão — ou a decidir se você realmente precisa de um.
RTL Quebra Tudo
Sua UI não foi projetada para árabe, hebraico ou urdu
Você trocou para dir="rtl" e viu seu layout explodir:
O que eu já vi:
- Sistemas de design com mais de 200 componentes onde apenas 12 lidam corretamente com RTL
- Equipes usando float: left em vez de propriedades lógicas, gerando bugs de RTL a cada nova funcionalidade
- Popovers e modais que exigem sobrescritas de RTL específicas por componente
- Frameworks que dizem ter "suporte RTL" mas só invertem a direção do layout e quebram a lógica de posicionamento
No que eu ajudo:
- Migração para propriedades lógicas CSS (margin-inline-start em vez de margin-left)
- Auditorias de sistema de design para encontrar armadilhas de RTL antes que cheguem à produção
- Orientação específica por framework (Tailwind, shadcn, MUI) para estilização RTL-first
Corrigir bugs de RTL manualmente em cada componente é insustentável. Eu torno o suporte a RTL sistemático, não uma batalha constante.
"O Texto em Alemão Quebrou Nosso Botão"
Interface que não foi pensada para tradução
O inglês cabe. O alemão não. Seu design partiu do princípio de que:
Aí você traduziu para alemão, finlandês ou tailandês e descobriu:
Botões cortados no meio da palavra
Tabelas com rolagem horizontal em cada linha
Texto que quebra em blocos ilegíveis
Texto não latino sendo truncado porque os contêineres têm largura fixa
No que eu ajudo:
- Padrões de UI flexíveis que se adaptam ao tamanho do conteúdo
- Planejamento de orçamento de caracteres (sabendo que o alemão expande 30 %, o tailandês não usa espaços)
- Sistemas de tipografia que lidam com CJK, árabe e devanágari sem quebrar
Eu ajudo você a construir uma interface do usuário que se adapta à tradução—antes que você pague por 10.000 palavras que não cabem.
Você não precisa de palestra sobre por que i18n é importante. Você precisa de alguém que já depurou popovers RTL às 2 da manhã, discutiu com o time de produto sobre limite de caracteres e projetou pipelines de tradução que realmente funcionam.
As pegadinhas sobre as quais ninguém te avisou
Histórias de guerra de times que já passaram por isso
Isso não é teoria. São coisas que quebraram em produção:
O inferno da pluralização
Inglês: "1 item" vs "2 items"
Polonês: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 formas de plural)
Árabe: 6 formas de plural
Sua lógica de count === 1 ? 'item' : 'items' não funciona mais.
Caos de data/hora
Você formatou datas com toLocaleDateString(). Aí usuários no Japão viram "2025年2月9日" nas exportações CSV e o Excel engasgou.
Incompatibilidade de idioma da API
Seu frontend solicita francês. Sua API retorna inglês porque o token de autenticação não carrega o locale. Resultado: uma UI com idiomas misturados e usuários achando que é um bug.
Teste com pseudo-locale
Você não testou com [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] antes de ir para produção. Agora seu site em polonês está inutilizável.
A suposição invisível
Você presumiu que as strings eram a única coisa que precisava de tradução. Então você se deparou com datas, números, moedas, ordenação, pesquisa—tudo com um comportamento específico de localidade.
No que eu ajudo:
- Implementação de ICU MessageFormat (gerencia plurais, gênero e contexto)
- Padrões de i18n para APIs (negociação de idioma, estratégias de fallback)
- Processos de QA que detectam esses problemas antes das agências de tradução
O fluxo de trabalho é a parte difícil
Como manter 8 idiomas sincronizados quando se faz deploy todo dia?
Você já dominou a tecnologia. Agora está travado no processo:
Desenvolvedores mesclam o código com novas strings em inglês. As traduções ficam atrasadas por 2 semanas. Os usuários veem uma interface do usuário parcialmente traduzida.
Você não sabe quais strings podem ser excluídas com segurança (estão em uso? traduzidas? em andamento com uma agência?)
A equipe de produto quer atualizar o texto. Ninguém sabe se mudar "Enviar" para "Mandar" vai quebrar 12 idiomas.
Arquivos de tradução ficam dessincronizados com a produção por semanas.
Perguntas que os times me fazem:
O que já vi quebrar:
- Arquivos de tradução no Git que divergem das strings de produção.
- Alertas de "não mexa no arquivo em espanhol" porque ninguém sabe o que é seguro alterar
- Funcionalidades lançadas em inglês e traduzidas 6 meses depois (quando muito)
No que eu ajudo:
- Design de pipeline de tradução (quando usar bibliotecas i18n, quando usar TMS, quando usar IA)
- Workflows Git para manter strings de origem e traduções sincronizadas
- Automação que bloqueia PRs se novas strings não estiverem marcadas para tradução
A tecnologia tem solução. O fluxo de trabalho é o gargalo. Eu projeto fluxos de trabalho que não exigem heroísmo para manter.
Equipes com as quais já trabalhei
Produtos globais, expertise regional
LINE (Japão, Taiwan, Tailândia)
Plataforma de mensagens presente em 3 mercados principais do Leste Asiático. Atuei em desafios específicos de manipulação de caracteres CJK, integração com ecossistemas de plataformas e expectativas de experiência do usuário que variam entre Japão, Taiwan e Tailândia.
KakaoTalk (Coreia do Sul)
Principal plataforma de mensagens da Coreia. Atendeu requisitos de produto específicos do mercado coreano, incluindo expectativas de formalidade do idioma na interface e necessidades de integração com a plataforma.
Change.org (196 países, mais de 20 idiomas prioritários)
Plataforma global de petições onde velocidade e qualidade do conteúdo fazem diferença. Ajudei a conduzir o fluxo de trabalho de tradução para conteúdo político e social gerado por usuários em mercados diversos.
Airbnb (mais de 220 países, mais de 60 idiomas)
Marketplace global com requisitos complexos de i18n. Consultoria sobre desafios de confiança e segurança em múltiplos idiomas e adaptação cultural de conceitos da plataforma em diferentes mercados.
Intercom (mais de 30 idiomas, SaaS B2B global)
Plataforma de comunicação com clientes atendendo clientes empresariais globais. Atuei na internacionalização do produto para ferramentas de suporte em tempo real e localização de base de conhecimento.
Lilith Games (China, Japão, Coreia, EUA, UE)
Editora de jogos mobile com títulos distribuídos globalmente. Enfrentou desafios específicos de cada mercado relacionados à localização de conteúdo e requisitos regionais de plataforma.
Mercados em que já lancei:
Leste Asiático (Japão, Coreia, China):
Tipografia CJK, integração com ecossistema de plataforma, suporte a texto vertical
Sudeste Asiático (Tailândia, Vietnã, Indonésia):
Suporte a múltiplos scripts, expectativas de usuários com foco em dispositivos móveis
MENA (regiões de língua árabe):
Requisitos de layout RTL, expectativas de idioma formal vs. coloquial, adaptação cultural de conteúdo
Europa:
24 idiomas oficiais, lançamentos de produto em vários países
Américas:
Variações regionais de idioma (espanhol latino-americano vs. espanhol europeu, português brasileiro), mercados bilíngues
Eu vi o que funciona e o que falha nesses mercados — não pela teoria, mas por ter lançado produtos dos quais usuários reais dependem.
Vamos Corrigir o Que Está Quebrando
Você não precisa de palestra sobre por que i18n é importante. Você precisa de alguém que já depurou popovers RTL às 2 da manhã, discutiu com o time de produto sobre limite de caracteres e projetou pipelines de tradução que realmente funcionam.
Revisão de arquitetura e estratégia (1–2 semanas):
Eu digo o que vai quebrar quando você adicionar seus próximos 3 idiomas — e quanto vai custar para corrigir
Suporte ao lançamento no mercado (4–8 semanas):
Você está fazendo o lançamento no Japão/MENA/EU e precisa de especialistas que já passaram por isso
Parceria contínua:
Consultoria integrada enquanto você escala de 2 para 20 idiomas
Eu não faço teoria. Eu faço triagem, roteiros e entregas.