Consulta de internacionalização: Corrigir o que está a falhar, planear o que vem a seguir
Já sabe que a internacionalização (i18n) é difícil. Já vi os sintomas: layouts RTL que colapsam, texto em alemão a transbordar dos botões, respostas de API na língua errada e traduções que perdem a sincronização poucas semanas após o lançamento. Não vendo soluções milagrosas. Ajudo-o a desembaraçar a confusão específica em que a sua equipa se encontra — e a criar sistemas que não vão falhar da mesma forma duas vezes.
«Devíamos ter planeado isto mais cedo»
O custo oculto da arquitetura que está a pagar agora
Lançou em inglês. Funcionou. Depois adicionou francês «só para a página de destino». Agora está aqui porque:
A sua base de código tem verificações de lang= espalhadas por 47 ficheiros
Os gestores de produto perguntam «podemos fazer testes A/B ao texto?» e a engenharia responde «não sem reescrever tudo»
Tem três workflows de tradução diferentes e nenhum deles funciona de forma fiável
O que já vi correr mal:
- Equipas a passar mais de 6 meses a adaptar i18n numa aplicação Next.js porque as strings estavam hard-coded nos componentes
- Ficheiros de tradução a ficarem dessincronizados porque os programadores não sabem qual ficheiro atualizar
- Períodos de «congelamento da localização» antes dos lançamentos porque ninguém confia no processo de tradução
- Resistência a alterar qualquer conteúdo traduzido porque o fluxo de trabalho é demasiado penoso
Em que ajudo:
- Estratégias de refatorização que lhe permitem adotar o i18n de forma incremental (não exijo «parar tudo e reescrever»)
- Conceção de processos para manter as traduções sincronizadas sem bloquear o desenvolvimento
- Revisões de arquitetura para identificar onde a sua abordagem atual vai falhar com mais de 10 línguas
i18n é arquitetura, não uma funcionalidade. Tentar adicioná-la depois é como decidir que a casa precisa de uma cave depois de já a ter construído.
Eu ajudo-o a escavar essa cave — ou a decidir se realmente precisa de uma.
RTL parte tudo
A sua UI não foi concebida para árabe, hebraico ou urdu.
Mudou para dir=«rtl» e viu o layout rebentar:
O que tenho visto:
- Sistemas de design com mais de 200 componentes em que apenas 12 lidam corretamente com RTL
- Equipas a usar float: left em vez de propriedades lógicas, a criar bugs RTL a cada nova funcionalidade
- Popovers e modais que exigem substituições RTL específicas por componente
- Frameworks que afirmam ter «suporte RTL», mas que apenas invertem a direção do layout e partem a lógica de posicionamento
Em que ajudo:
- Migração para propriedades lógicas de CSS (margin-inline-start em vez de margin-left)
- Auditorias ao sistema de design para detetar minas RTL antes do lançamento
- Orientação específica por framework (Tailwind, shadcn, MUI) para estilização RTL-first
Corrigir manualmente erros RTL em cada componente é insustentável. Torno o suporte RTL sistemático, em vez de andar sempre a apagar fogos.
«O texto em alemão rebentou com o nosso botão»
UI que não foi pensada para tradução
O inglês cabe. O alemão não. O seu design partiu do princípio de que:
Depois traduziu para alemão, finlandês ou tailandês e descobriu:
Botões cortados a meio da palavra
Tabelas com deslocamento horizontal em todas as linhas
Texto que se parte em blocos ilegíveis
Texto não latino truncado porque os contentores têm larguras fixas
Em que ajudo:
- Padrões de UI elásticos que se adaptam ao tamanho do conteúdo
- Planeamento do orçamento de caracteres (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 problemas
Ajudo-o a criar uma UI que resiste à tradução — antes de ter pago por 10 000 palavras que não cabem.
Não precisa de uma lição sobre a importância do i18n. Precisa de alguém que já tenha feito debug de popovers RTL às 2 da manhã, discutido com o produto sobre limites de caracteres e criado pipelines de tradução que realmente funcionam.
As armadilhas de que ninguém lhe falou
Histórias de guerra de equipas que já passaram por isto
Isto não é teórico. São coisas que rebentaram em produção:
O inferno da pluralização
Inglês: «1 item» vs «2 items»
Polaco: «1 przedmiot» / «2 przedmioty» / «5 przedmiotów» (3 formas de plural)
Árabe: 6 formas de plural
A sua lógica count === 1 ? 'item' : 'items' já não funciona.
Caos de data e hora
Formatou as datas com toLocaleDateString(). Depois, os utilizadores no Japão viram «2025年2月9日» nas exportações CSV e o Excel bloqueou.
Incompatibilidade linguística na API
O seu frontend pede francês. A sua API devolve inglês porque o token de autenticação não inclui o locale. Agora tem uma interface com línguas misturadas e utilizadores que pensam que é um bug.
Testes com pseudo-localização
Não testou com [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] antes de colocar em produção. Agora, o seu site em polaco está inutilizável.
O pressuposto invisível
Partiu do princípio de que as strings são a única coisa que precisa de tradução. Depois deparou-se com datas, números, moedas, ordenação, pesquisa — tudo tem comportamento específico por localidade.
Em que ajudo:
- Implementação de ICU MessageFormat (trata plurais, género, contexto)
- Padrões de i18n para APIs (negociação de língua, estratégias de contingência)
- Processos de QA que detetam estes problemas antes das agências de tradução
O fluxo de trabalho é a parte difícil
Como manter 8 línguas sincronizadas quando se lançam versões todos os dias?
Já domina a tecnologia. Agora está bloqueado no processo:
Os programadores fazem merge de código com novas strings em inglês. As traduções atrasam-se 2 semanas. Os utilizadores veem uma UI meio traduzida.
Não sabe quais strings é seguro eliminar (estão a ser usadas? traduzidas? em curso com uma agência?)
O produto quer atualizar o texto. Ninguém sabe se mudar «Submit» para «Send» vai partir 12 línguas.
Os ficheiros de tradução ficam dessincronizados com a produção durante semanas seguidas
Perguntas que as equipas me fazem:
O que já vi correr mal:
- Ficheiros de tradução registados no git que divergem das strings em produção
- Avisos de «Não mexam no ficheiro espanhol» porque ninguém sabe o que é seguro alterar
- Funcionalidades lançadas em inglês e traduzidas 6 meses depois (se é que chegaram a ser)
Em que ajudo:
- Conceção do pipeline de tradução (quando usar bibliotecas i18n, quando usar um TMS, quando usar IA)
- Fluxos de trabalho Git para manter as strings de origem e as traduções sincronizadas
- Automatização que bloqueia PRs se as novas strings não estiverem marcadas para tradução
A tecnologia tem solução. O fluxo de trabalho é que é o problema. Concebo fluxos de trabalho que não exigem heroísmos para manter.
Equipas com quem trabalhei
Produtos globais, especialização regional
LINE (Japão, Taiwan, Tailândia)
Plataforma de mensagens presente em 3 mercados principais do Leste Asiático. Trabalhei em desafios específicos relacionados com o tratamento de caracteres CJK, a integração no ecossistema da plataforma e as expectativas de experiência do utilizador, que diferem entre o Japão, Taiwan e a Tailândia.
KakaoTalk (Coreia do Sul)
A plataforma de mensagens dominante na Coreia. Abordei requisitos específicos do mercado coreano, incluindo expectativas de formalidade linguística na interface e necessidades de integração com a plataforma.
Change.org (196 países, mais de 20 línguas prioritárias)
Plataforma global de petições, onde a rapidez e a qualidade do conteúdo são essenciais. Ajudei a estruturar o fluxo de trabalho de tradução para conteúdo político e social gerado pelos utilizadores em mercados diversificados.
Airbnb (mais de 220 países, mais de 60 línguas)
Mercado global com requisitos complexos de i18n. Prestei consultoria sobre desafios de confiança e segurança em várias línguas e adaptação cultural de conceitos da plataforma a diferentes mercados.
Intercom (mais de 30 línguas, B2B SaaS global)
Plataforma de comunicação com clientes ao serviço de grandes empresas a nível global. Trabalhei na internacionalização do produto para ferramentas de suporte em tempo real e na localização da base de conhecimento.
Lilith Games (China, Japão, Coreia, EUA, UE)
Editora de jogos móveis com títulos distribuídos a nível global. Abordei desafios específicos de cada mercado, relacionados com a localização de conteúdos e os requisitos regionais das plataformas.
Mercados em que lancei:
Ásia Oriental (Japão, Coreia, China):
Tipografia CJK, integração no ecossistema da plataforma, suporte de texto vertical
Sudeste Asiático (Tailândia, Vietname, Indonésia):
Suporte a múltiplos sistemas de escrita, expectativas do utilizador orientadas para o móvel
MENA (regiões de língua árabe):
Requisitos de layout RTL, expectativas de registo formal vs. coloquial, adaptação cultural de conteúdo
Europa:
24 línguas oficiais, lançamentos de produto em vários países
Américas:
Variações regionais da língua (espanhol da América Latina vs. Espanha, português do Brasil), mercados bilingues
Vi o que funciona e o que falha nestes mercados — não com base em teoria, mas ao lançar produtos de que utilizadores reais dependem.
Vamos corrigir o que está a falhar
Não precisa de uma lição sobre a importância do i18n. Precisa de alguém que já tenha feito debug de popovers RTL às 2 da manhã, discutido com o produto sobre limites de caracteres e criado pipelines de tradução que realmente funcionam.
Revisão da arquitetura e estratégia (1-2 semanas):
Digo-lhe o que vai falhar quando adicionar as próximas 3 línguas e quanto custará corrigir
Apoio ao lançamento no mercado (4-8 semanas):
Está a lançar no Japão/MENA/UE e precisa de especialistas que já o tenham feito antes
Parceria contínua:
Consultoria integrada à medida que escala de 2 para 20 línguas
Não faço teoria. Faço triagem, roadmaps e lançamentos.