10 erros comuns de i18n e como evitá-los
Conheça os erros de internacionalização mais comuns que os desenvolvedores cometem e como corrigi-los. Melhore a qualidade de localização do seu aplicativo com estas melhores práticas.
Internationalisierung (i18n) parece simples — até descobrires que os teus utilizadores alemães veem botões cortados, os teus utilizadores japoneses recebem fragmentos de frases cortados e os falantes de árabe têm layouts completamente desadequados. Não são casos isolados. São as consequências previsíveis dos erros mais comuns que as equipas de desenvolvimento cometem ao encarar a localização pela primeira vez. Neste guia vamos abordar os 10 erros de i18n mais comuns, explicar exatamente por que acontecem e mostrar, passo a passo, como corrigir cada um. Quer tenhas uma app nova ou estejas a atualizar uma já existente — evitar estas armadilhas poupa-te semanas de debugging.
Erro #1: Strings codificados no código
Strings codificados diretamente no código-fonte são o erro i18n mais fundamental. Acontece porque os desenvolvedores se concentram primeiro em fazer as funcionalidades funcionarem e planeiam 'arrumar depois'. Mas o depois nunca chega, e de repente tens milhares de strings espalhadas por centenas de ficheiros.
['Configure o seu framework i18n antes de escrever a primeira linha do código da UI', 'Use um plugin de linter para detectar strings codificadas diretamente em templates e componentes', 'Mantenha as chaves de tradução descritivas e organizadas por recurso ou página']
Configure o teu i18n framework antes de escrever a primeira linha de código da UI.
Utilize um plugin de lint para detetar strings codificadas em templates e componentes.
Mantenha as chaves de tradução descritivas e organizadas por recurso ou por página.
Um cenário típico
Um desenvolvedor escreve o rótulo de um botão diretamente no JSX: <button>Submit Order</button>.
A app é entregue em inglês e funciona perfeitamente. Seis meses depois, a empresa expande para a Alemanha.
A equipa de localização descobre 2.000+ strings codificadas. A atualização leva 3 semanas e provoca 47 bugs.
Por que isso é um problema
Em uma base de código madura, strings hardcodadas podem chegar a milhares. Removê-las depois exige tocar cada ficheiro, testar novamente cada componente e arriscar regressões.
Strings codificadas diretamente no código-fonte, templates ou componentes estão embutidas. Não podem ser extraídas, traduzidas ou trocadas em tempo de execução sem alterar o próprio código.
Utilizadores em locais que não são ingleses veem elementos da interface não traduzidos misturados com conteúdo traduzido — uma impressão caótica e pouco profissional.
Como resolver isto
Desloque todos os textos visíveis ao usuário desde o início para arquivos de recursos.
Rette um framework de tradução (por exemplo, next-intl, react-i18next, vue-i18n) antes de escrever a sua primeira componente.
Crie uma estrutura de arquivos de recursos (por exemplo, messages/de.json) e referencie todos os textos através de chaves de tradução como t('checkout.submitButton').
Adicione uma regra de lint ou um gancho de pre-commit que sinalize literais de string crus nas componentes de UI.
Erro #10: Traduzir tudo literalmente
Nem todo conteúdo deve ser traduzido. Nomes de marcas, nomes de pessoas jurídicas, termos técnicos específicos e certos nomes de produtos devem permanecer na língua original. Tradução em excesso pode causar problemas legais, inconsistência de marca e confusão para o utilizador.
["Mantenha um glossário 'Não traduzir' e compartilhe-o com todos os tradutores", 'Use segmentos bloqueados ou namespaces separados para termos de marca e termos legais', 'Forneça sempre notas de contexto para cadeias de caracteres ambíguas, a fim de evitar traduções incorretas']
Mantenha um glossário de 'não traduzir' e compartilhe-o com todos os tradutores.
Use segmentos bloqueados ou namespaces separados para termos de marca e termos legais.
Forneça sempre notas de contexto para strings ambíguas, para evitar traduções incorretas
Um cenário típico
Um ficheiro de tradução contém o nome da empresa 'CloudForge Inc.' e o termo técnico 'OAuth 2.0 Token' como strings traduzíveis normais.
O tradutor espanhol traduz 'CloudForge' para 'ForjaNube' e 'OAuth 2.0 Token' para 'token OAuth 2.0'.
Resultado: os usuários não encontram a empresa pelo nome real, e os desenvolvedores que leem a documentação em espanhol ficam confusos com termos técnicos traduzidos de forma desconhecida.
Por que isto é um problema
Um único nome de marca mal traduzido em um documento legal pode tornar contratos inválidos. Corrigir traduções excessivas requer a verificação de cada string em cada idioma — um trabalho de várias semanas.
Se todas as strings forem enviadas para tradução sem contexto, os tradutores podem traduzir nomes de marcas ('Apple' → 'Maçã'), termos jurídicos ('GmbH' → 'LLC') ou termos técnicos que devem permanecer em inglês.
Os utilizadores não encontram produtos pelo nome de marca conhecido, documentos legais referenciam a empresa errada e a documentação técnica torna-se confusa quando termos como 'API Endpoint' são traduzidos.
Como resolver isto
Marque claramente conteúdos que não devem ser traduzidos e forneça notas de contexto aos tradutores.
Crie um glossário 'Não traduzir' que liste todos os nomes de marcas, nomes de produtos, pessoas jurídicas e termos técnicos que precisam permanecer inalterados.
Use um namespace separado ou chaves especiais para conteúdos que não devem ser traduzidos. Muitas ferramentas i18n suportam segmentos 'bloqueados' que os tradutores não podem editar.
Adicione comentários/descrições para os tradutores nos seus arquivos de tradução, explicando o contexto: 'Este é um nome de marca — não traduzir' ou 'Termo técnico — manter em inglês'.
Erro #2: Concatenação de strings
Colar frases a partir de fragmentos parece lógico em inglês, funciona, porém, em outras línguas, a ordem das palavras, gramática e construção de frases variam drasticamente, o que torna frases encadeadas não traduzíveis.
['Nunca construa frases concatenando fragmentos traduzidos', 'Use placeholders nomeados ('{name}') ao invés de posicionais ({0}) para maior clareza', 'Forneça comentários de contexto para tradutores explicando o conteúdo de cada placeholder']
Nunca construa frases juntando fragmentos traduzidos.
Use placeholders nomeados ('{name}') ao invés de posicionais ({0}) para maior clareza
Forneça comentários de contexto para tradutores, explicando o que cada placeholder contém
Um cenário típico
O desenvolvedor escreve: 'Você tem ' + count + ' itens no seu carrinho de compras ' + cartType + ' cart' — funciona perfeitamente em inglês.
O tradutor alemão recebe três fragmentos separados e não consegue formar uma frase gramaticalmente correta, porque a ordem das palavras precisa de mudar.
Resultado: Os utilizadores alemães veem 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — desajeitado e pouco profissional.
Por que isso é um problema
Cada string encadeada é uma bomba-relógio. Com 20 idiomas e 50 strings encadeadas, você tem 1.000 potenciais erros gramaticais que precisam de ser corrigidos manualmente.
A concatenação de strings como 'Willkommen ' + userName + ', você tem ' + count + ' novas mensagens' pressupõe uma ordem de palavras específica. Tradutores recebem fragmentos sem contexto que não podem rearranjar.
Os utilizadores veem frases gramaticalmente incorretas. Em alemão, o verbo costuma ficar no final. Em árabe, toda a estrutura é invertida. O resultado soa a parvoíce.
Como resolvê-lo
Use mensagens parametrizadas com marcadores nomeados, para que os tradutores possam reorganizar a frase inteira.
Substitua concatenação por uma única chave de mensagem com placeholders: 'cart.summary': 'Você tem {count} itens no seu carrinho '{cartType}''.
Passe as variáveis como parâmetros para a sua função de tradução: t('cart.summary', { count: 5, cartType: 'Premium' }).
Tradutores podem reorganizar livremente: 'No seu carrinho '{cartType}', há {count} itens' — alemão gramaticalmente correto.
Erro #3: Ignorar a pluralização
O inglês tem duas formas de plural: singular e plural. Os desenvolvedores costumam supor que todas as línguas funcionam da mesma forma. Não funcionam. O polonês tem 4 formas, o árabe tem 6, e até línguas como o francês tratam o zero de forma diferente do inglês.
['Utilize sempre ICU MessageFormat ou uma biblioteca equivalente para conteúdos contáveis', 'Nunca escreva lógica de plural própria — confie nas regras CLDR', 'Teste plurais com valores como 0, 1, 2, 5, 21 e 100 para cobrir todas as categorias']
Utilize sempre ICU MessageFormat ou uma biblioteca equivalente para conteúdos com pluralização.
Nunca escreva lógica de plural própria — confie nas regras CLDR.
Teste os plurais com valores como 0, 1, 2, 5, 21 e 100, para cobrir todas as categorias.
Um cenário típico
O desenvolvedor escreve: count + (count === 1 ? ' Ficheiro' : ' Ficheiros') — trata o alemão corretamente.
O tradutor polonês precisa de 4 formas: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. O operador ternário simples não consegue expressar isso.
Resultado: Os utilizadores polacos veem '5 pliki' (forma incorreta) em vez de '5 plików' (forma correta), e a aplicação parece estar partida.
Por que isto é um problema
Cada substantivo contável na sua app precisa de tratamento de plural. Com 50 strings desse tipo e 20 idiomas, são 1.000 regras de plural — impossível de gerir manualmente.
Verificações simples com if/else (count === 1 ? 'Ficheiro' : 'Ficheiros') tratam apenas alemão/inglês. O CLDR define até 6 categorias de plural: zero, one, two, few, many e other. Cada língua utiliza um subconjunto diferente.
Os utilizadores veem textos gramaticalmente incorretos, como '1 Nachrichten', ou formas de plural totalmente incorretas. Em contextos formais, isso corrói a credibilidade.
Como resolvê-lo
Use ICU MessageFormat, que já suporta, de forma nativa, todas as regras de plural do CLDR.
Defina mensagens com a sintaxe ICU: 'fileCount': '{count, plural, one {# Ficheiro} other {# Ficheiros}}'.
Tradutores fornecem todas as formas de plural necessárias para a sua língua. Polonês: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
A sua biblioteca i18n seleciona automaticamente, em tempo de execução, a forma correta com base nas regras CLDR da localidade ativa.
Erro #4: Largura fixa de elementos de UI
Designers criam layouts com pixel-perfeito em inglês, e os desenvolvedores os implementam com larguras fixas. No entanto, o texto traduzido pode ficar drasticamente mais longo ou mais curto. O texto em alemão é cerca de 30% mais longo que o inglês, enquanto o chinês pode ser cerca de 50% mais curto.
['Nunca use larguras fixas em pixels em elementos com texto traduzível', 'Planeie para 40% de expansão de texto como baseline — algumas línguas expandem ainda mais', 'Use CSS Flexbox ou Grid para layouts que se adaptem a comprimentos variáveis de conteúdo']
Não utilize larguras de pixels fixas em elementos com texto traduzível.
Planeje uma linha de base de expansão de 40% de texto — algumas línguas expandem ainda mais.
Use CSS Flexbox ou Grid para layouts que se adaptam a comprimentos de conteúdo variáveis.
Um cenário típico
O designer cria uma barra de navegação com 5 botões, cada um com exatamente 100px de largura — fica ótima em inglês.
Tradução alemã: 'Settings' torna-se 'Configurações' (13 vs 8 caracteres), 'Submit' torna-se 'Enviar' (6). A barra de navegação transborda.
Resultado: Em dispositivos móveis, os botões ficam empilhados ou o texto fica cortado, tornando a navegação inútil para os usuários alemães.
Por que isto é um problema
Cada elemento com largura fixa é um ponto de ruptura em potencial. Um aplicativo típico tem centenas de botões, rótulos e cartões, que precisam suportar a expansão do texto.
Contêineres com largura fixa (width: 120px) e botões de tamanho fixo cortam o conteúdo ou transbordam quando o texto se expande. overflow: hidden no CSS esconde o conteúdo silenciosamente, enquanto overflow: visible distrói o layout.
Os usuários veem rótulos cortados como 'Configura...' em vez de 'Configurações', ou botões que sobrepõem elementos vizinhos. Ações críticas ficam ilegíveis ou não clicáveis.
Como corrigir isto
Projete e implemente layouts flexíveis que se adaptem ao comprimento do conteúdo de todas as Locales.
Substitua larguras fixas por min-width, max-width e layouts flexíveis. Use CSS Grid ou Flexbox para distribuir o espaço dinamicamente.
Defina o contêiner de texto para quebra de linha: use overflow-wrap: break-word e evite white-space: nowrap em conteúdo traduzível.
Teste sua interface com pseudo-localização que estende todas as strings em 40% para simular o pior cenário — ainda antes de enviar as strings aos tradutores.
Erro #5: Formato de data e número
Dados e números parecem universais. Mas 01/02/2025 significa 2 de janeiro nos EUA e 1 de fevereiro na Europa. Vírgulas e pontos trocam de significado em números: 1,000.50 (EUA) vs 1.000,50 (Brasil). Fazer isso de forma incorreta leva a confusão, erros de dados e perda de confiança.
['Não formate dados ou números manualmente com modelos de string — use sempre as APIs Intl', 'Guarde todos os dados em ISO 8601 e moedas na menor unidade (cent) internamente', 'Teste com Locais que utilizem separadores decimais diferentes, ordens de datas e calendários diferentes']
Não formate dados ou números manualmente com templates de string — use sempre as APIs Intl.
Armazene todos os dados em ISO 8601 e moedas na menor unidade (centavos) internamente.
Teste com locais que utilizam separadores decimais diferentes, ordens de data e calendários.
Um cenário típico
O desenvolvedor formata uma data como MM/DD/AAAA e um preço como $1.234,50 — correto para utilizadores dos EUA.
Um utilizador alemão vê a data 03/04/2025 e lê-a como 3 de abril em vez de 4 de março — compromissos perdidos ou reservas incorretas.
Resultado: O utilizador reserva um voo para a data errada e questiona o formato de preço. Os pedidos de suporte aumentam no mercado alemão em 15%.
Por que isto é um problema
A formatação de datas e números afeta qualquer exibição de dados na tua app: tabelas, gráficos, formulários, faturas, relatórios. Um fix global cobre centenas de instâncias.
Strings de formato codificadas como toLocaleDateString('en-US') ou formatação manual com literais de template ignoram a localidade real do utilizador. Mesmo a localidade correta, mas o calendário errado (gregoriano vs hijri) causa problemas.
Os usuários leem dados incorretamente e inserem dados no formato errado. Um utilizador europeu que vê 03/04/2025 pode interpretá-lo como 3 de abril em vez de 4 de março — compromissos perdidos ou reservas incorretas.
Como resolver isto
Use a API Intl integrada ou uma biblioteca de formatação que respeite a localidade para todas as datas, horários, números e moedas.
Substitua a formatação manual por Intl.DateTimeFormat(locale) para datas e Intl.NumberFormat(locale, { style: 'currency', currency }) para preços.
Armazene os dados internamente no formato ISO 8601 (YYYY-MM-DD) e formate-os apenas para exibição com a locale do utilizador.
Teste com pelo menos 5 locais diferentes: en-US, de-DE, ja-JP, ar-SA e zh-CN, para cobrir as principais variantes de formatação.
Erro #6: Esquecer idiomas RTL
Línguas da direita para esquerda (RTL), como Árabe, Hebraico e Persa, são usadas por mais de 500 milhões de pessoas. Ainda assim, a maioria dos apps é desenhada apenas para layouts da esquerda para a direita (LTR). O suporte RTL não significa apenas inverter o texto — toda a interface precisa ser espelhada.
['A partir do primeiro dia utilize exclusivamente propriedades CSS lógicas (inline-start/end, block-start/end)', 'Teste a tua app com dir='rtl' no elemento HTML em cada sprint-review', 'Crie uma checklist de teste RTL para navegação, ícones, formulários e indicadores de progresso']
Use desde o primeiro dia apenas propriedades CSS lógicas (inline-start/end, block-start/end).
Teste o seu aplicativo com dir='rtl' no elemento HTML em cada revisão de sprint.
Crie uma checklist RTL para navegação, ícones, formulários e indicadores de progresso.
Um cenário típico
Desenvolvedor usa margin-left: 16px e text-align: left por toda a aplicação — prática padrão de LTR.
A app inicia na Arábia Saudita. Setas de voltar aparecem na direção errada, as sidebars aparecem no lado errado, e os dados numéricos ficam desalinhados.
Resultado: Usuários árabes abandonam a app após 30 segundos. A equipa precisa de 4 semanas para um refator CSS de emergência para resolver o problema.
Por que isso é um problema
O suporte RTL afeta cada componente da sua app. Introduzir RTL mais tarde normalmente requer reescrever 30-50% de todas as regras CSS e verificar cada ícone e layout.
Propriedades CSS como margin-left, padding-right, text-align: left e float: left codificam a direção. Ícones com significado de direção (setas, indicadores de progresso) apontam na direção errada. Mesmo os valores de border-radius precisam ser espelhados.
Navegadores árabes veem a navegação na esquina errada, a barra de progresso corre ao contrário e textos que colidem com elementos da UI. O app parece estranho e impossível de usar.
Como resolves isto
Use propriedades CSS lógicas e teste com layout RTL desde o início.
Substitua todas as propriedades CSS físicas por equivalentes lógicos: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Defina o atributo dir no elemento raiz HTML com base na localidade ativa. Use a pseudo-classe CSS :dir(rtl) para substituições RTL específicas.
Verifique todos os ícones quanto ao significado direcional. Substitua ícones com orientação por versões espelhadas ou use CSS transform: scaleX(-1) para contextos RTL.
Erro #7: Imagens com texto
Text em imagens — seja em banners de destaque (hero), botões, infográficos ou capturas de tela — é um pesadelo de localização. Cada imagem com texto precisa ser recriada para cada idioma, o que multiplica os custos de design e atrasa os lançamentos.
['Melhor tradução de texto nunca colocar diretamente em imagens raster (PNG, JPG)', 'Utilize overlays de texto CSS em imagens de fundo para banners hero e CTAs', 'Automatize a geração de capturas de tela para listagens da App Store e páginas de marketing']
Nunca insira texto traduzível diretamente em imagens raster (PNG, JPG).
Use overlays de texto CSS em imagens de fundo para banners hero e CTAs.
Automatize a geração de capturas de tela para listagens da App Store e páginas de marketing.
Um cenário típico
Um designer cria um banner promocional com o texto 'Start Your Free Trial' inserido diretamente na imagem.
A equipa de localização traduz todas as strings da UI, mas o banner ainda mostra texto em inglês na página alemã.
Resultado: a landing page alemã tem um banner irritante em inglês. Criar banners localizados para 15 idiomas leva 3 dias de trabalho de design e atrasaria o lançamento.
Por que isto é um problema
Uma página típica de marketing tem 5-10 imagens com texto. Em 15 idiomas, isso representa 75-150 variantes de imagens que precisam de ser criadas, mantidas e atualizadas a cada alteração de design.
Texto embutido em imagens (PNG, JPG, SVG com texto embutido) não pode ser extraído por ferramentas de tradução. Cada versão localizada exige que um designer edite manualmente o arquivo-fonte, exporte e carregue.
Os utilizadores veem imagens com texto noutra língua, ou pior, uma mistura de UI traduzida com imagens não traduzidas. Isto parece inconsistente e abala a confiança na marca.
Como resolvê-lo
Separe o texto das imagens usando overlays em CSS, SVGs com elementos de texto que podem ser traduzidos ou geração dinâmica de imagens.
Use CSS para colocar texto traduzível sobre imagens de fundo: posicione a camada de texto com position: absolute sobre o contêiner da imagem.
Para infográficos ou diagramas, use SVGs com elementos <text> que façam referência a chaves de tradução, em vez de incorporar strings brutas.
Para capturas de tela de apps em materiais de marketing, automatize a geração de capturas com ferramentas como Fastlane (Mobile) ou Playwright (Web), que tiram screenshots em cada locale.
Erro #8: Traduções ausentes não tratadas
Traduções durante o desenvolvimento estão sempre incompletas. Novas funcionalidades adicionam strings mais rapidamente do que os tradutores as traduzem. Sem um tratamento de fallback adequado, traduções ausentes causam falhas, elementos de UI vazios ou chaves de tradução brutas que aparecem aos utilizadores.
['Configure sempre pelo menos uma língua de fallback na sua configuração de i18n', 'Registe as chaves de tradução ausentes no seu sistema de monitorização para acompanhamento', 'Defina um nível mínimo de cobertura de tradução antes de tornar uma locale ativa']
Configure sempre pelo menos uma língua de fallback no seu i18n.
Registre as chaves de tradução ausentes no seu sistema de monitoramento para acompanhamento.
Defina um nível mínimo de cobertura de tradução antes de uma locale ficar ativa.
Um cenário típico
O desenvolvedor adiciona uma nova área 'Recursos Premium' com 15 novas chaves de tradução. A versão em inglês é entregue imediatamente.
As traduções em francês ainda não estão prontas. A página francesa mostra chaves brutas: 'premium.feature1.title', 'premium.feature1.description'.
Resultado: utilizadores franceses veem uma página cheia de nomes de chaves de desenvolvedor. A equipa de suporte recebe dezenas de relatos de bugs.
Por que isto é um problema
À medida que a tua app cresce, a lacuna entre strings em inglês e traduções em outras línguas cresce. Uma aplicação com 100 línguas e 2.000 strings pode ter, a qualquer momento, mais de 10.000 traduções em falta.
Sem lógica de fallback, uma chave de tradução ausente devolve undefined, null ou a string bruta da chave (por exemplo 'checkout.confirmButton'). Mecanismos de template podem gerar erros, fazer com que a página falhe ou não renderize nada.
Os utilizadores veem uma UI danificada: botões vazios, rótulos ausentes ou strings enigmáticas como 'nav.settings.title' em vez de texto real. Isto é confuso e pouco profissional.
Como resolvê-lo
Configure uma cadeia robusta de fallback e monitorize a cobertura de traduções em todas as Locales.
Configure uma cadeia de fallback de idioma na configuração i18n: chaves em francês (fr) que estejam ausentes caem automaticamente para o inglês (en).
Adicione um tratador de chaves ausentes que registre as chaves não traduzidas no seu sistema de monitorização (por exemplo, Sentry, Datadog), sem quebrar a experiência do utilizador.
Crie um dashboard de cobertura de traduções que acompanhe o nível de conclusão por locale e bloqueie lançamentos se a cobertura cair abaixo de um limiar (ex.: 95%).
Erro #9: Problemas de codificação de caracteres
Problemas de codificação de caracteres são o assassino silencioso da localização. Tudo parece correto em inglês e nas línguas europeias, mas assim que adicionas chinês, japonês, coreano, árabe ou emoji, aparecem caracteres corrompidos (mojibake). Esses bugs são notoriamente difíceis de detetar.
['Use codificação UTF-8 em todos os lugares — arquivos-fonte, banco de dados, respostas de API e meta tags HTML', 'Utilize utf8mb4 no MySQL (não utf8) para suportar todo o conjunto Unicode, incluindo emoji', 'Teste com conteúdo real em CJK, árabe e emoji, para detectar problemas de codificação cedo']
Use codificação UTF-8 em todo lugar — arquivos-fonte, banco de dados, respostas da API e meta-tags HTML.
Use utf8mb4 no MySQL (não utf8) para suportar todo o conjunto Unicode, incluindo Emoji.
Teste com conteúdo real em CJK, árabe e emoji para detectar problemas de codificação cedo.
Um cenário típico
Os desenvolvedores configuram uma base de dados MySQL com collation latin1 (o antigo padrão). O código-fonte da aplicação usa UTF-8.
Os utilizadores japoneses registram-se com o seu nome real. O banco de dados armazena '田中太郎' como bytes corrompidos.
Resultado: o perfil do utilizador exibe texto mutilado. Pior ainda: a pesquisa e a ordenação falham para todos os nomes CJK, afetando milhares de utilizadores.
Por que isto é um problema
Problemas de codificação espalham-se por todo o seu stack. Uma collation de base de dados mal configurada pode corromper milhões de registos — corrigir isso requer migrações de dados dispendiosas.
Codificação inconsistente em todo o stack — UTF-8 nos ficheiros de origem, Latin-1 na base de dados e Windows-1252 nas respostas da API — transforma caracteres multibyte em '????' ou '日本èª'.
Os utilizadores veem textos cortados, sinais de interrogação ou caixas vazias onde deveria estar a língua deles. No pior caso, as entradas de formulários ficam permanentemente danificadas na base de dados.
Como corrigir isto
Imponha codificação UTF-8 consistente em todas as camadas do seu stack de aplicação.
Defina todos os ficheiros-fonte para UTF-8 (configure o seu editor e .editorconfig). Adicione <meta charset='UTF-8'> no HTML e 'Content-Type: application/json; charset=utf-8' nas respostas da API.
Configure a base de dados para utf8mb4 (não apenas utf8, o que no MySQL é um subconjunto de 3 bytes). Defina a collation da ligação para utf8mb4_unicode_ci.
Escolha fontes que cubram os seus sistemas de escrita-alvo: Latim, Cirílico, CJK, Árabe, Devanagari. Use stacks de fontes do sistema ou Google Fonts com subconjuntos de idioma para um carregamento ótimo.
Teste a sua implementação de i18n
Teste de extensão de comprimento
Aumente todos os strings traduzidos em 30-40% para simular o aumento de texto que ocorre em idiomas com maior extensão de palavras, como alemão, finlandês ou grego. Isso cobre contêineres de largura fixa, rótulos cortados e botões que transbordam antes de você começar a traduzir. Muitas ferramentas de pseudo-localização já oferecem isso como recurso embutido.
"Enviar" → "Enviar_40%_mais_longo" (40% mais longo)
Pseudolocalização
Pseudolocalização substitui cada caractere por um equivalente acentuado (por exemplo, 'a' → 'á') e envolve strings com marcadores como [!! e !!]. Assim fica imediatamente visível quais cadeias estão codificadas diretamente e quais vêm do sistema de tradução. Execute a pseudolocalização como parte da sua pipeline de CI para detectar regressões automaticamente.
Todo o texto na tela que não estiver entre [!! !!] marcações está codificado de forma fixa e precisa ser externalizado. Este teste captura 95% das strings negligenciadas em menos de um minuto.
"Enviar mensagem" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Teste de layout RTL
Mesmo sem traduções em árabe ou hebraico, você pode testar o layout RTL adicionando dir='rtl' ao elemento raiz HTML. Isso detecta rapidamente bugs de direção no CSS: ícones desalinhados, margens no lado errado, navegação quebrada e itens flex com ordenação incorreta. Torne isso uma verificação padrão em cada sprint — leva 10 segundos para alternar e captura problemas que, de outra forma, levariam semanas para corrigir em produção.
A lista de verificação i18n
['Todos os textos visíveis ao usuário devem estar em arquivos de recursos', 'Não utilize concatenação de strings para formar frases', 'Regras de pluralização com ICU MessageFormat ou equivalente implementadas', 'Formatações de data, hora e números utilizam APIs sensíveis à localidade', 'Layout RTL com conteúdos em árabe ou hebraico testados', 'UI flexível sem larguras fixas para elementos com texto', 'Idioma de fallback configurado e testado para chaves ausentes', 'Codificação UTF-8 consistente em todos os arquivos e bancos de dados', 'Metadados da App Store e Play Store localizados para cada mercado', 'Capturas de tela e ativos de marketing atualizados para cada idioma']