Uma string com gênero codificado no texto em inglês quebra assim que chega ao português. "You have 1 new message" vira plural gramatical em quase todas as línguas latinas, e um arquivo de recursos mal preparado obriga o tradutor a adivinhar se "1" é singular ou se o sistema vai realmente mostrar "1 mensagens" para o usuário final. Isso não é um detalhe de estilo. É um bug de localização que chega até a produção.
Este artigo cobre o que separa um arquivo de recursos pronto para localizar de um que vai gerar idas e voltas, strings truncadas e plurais errados em produção.
Separar texto de lógica desde o início
Um erro comum em equipes que localizam pela primeira vez é concatenar strings no código. `"O usuário " + nome + " tem " + numero + " mensagens"` funciona em inglês e falha em qualquer língua com ordem de palavras diferente ou com concordância de gênero e número. O alemão move o verbo para o fim da frase em orações subordinadas. O árabe se lê da direita para a esquerda. Nenhuma dessas línguas respeita a ordem fixa que o código em inglês assume.
A prática correta é usar strings completas com placeholders nomeados, não posicionais: `"O usuário {userName} tem {messageCount} mensagens"`. Isso permite ao tradutor reordenar os elementos conforme a gramática do idioma de destino, sem mexer na lógica do código. Frameworks como ICU MessageFormat, Fluent (Mozilla) ou os arquivos .resx do .NET já suportam esse padrão de forma nativa.
Outro ponto que gera retrabalho: separar frases em pedaços que só fazem sentido remontados. "Clique" + "aqui" + "para continuar" como três strings distintas impede o tradutor de entender o contexto e muitas vezes resulta numa frase gramaticalmente incorreta quando reconstruída. Cada string deve ser uma unidade de sentido completa.
Plurais: a regra do inglês não serve para mais ninguém
O inglês tem dois plurais: singular e plural. O português também, mas com concordância de gênero que o inglês não tem. O polonês tem quatro formas plurais diferentes dependendo de o número terminar em 1, em 2-4, ou em outro dígito. O árabe tem seis categorias gramaticais de plural. Um arquivo de recursos preparado apenas com `one` e `other` quebra assim que o projeto precisa suportar russo ou árabe.
O padrão CLDR (Common Locale Data Repository), mantido pelo Unicode Consortium, define as categorias de plural (`zero`, `one`, `two`, `few`, `many`, `other`) que cada língua realmente usa. A maioria dos frameworks modernos de internacionalização (i18next, Fluent, gettext com plural forms, ICU MessageFormat) já implementa essas categorias. A preparação correta do arquivo fonte passa por:
- Nunca concatenar números a strings fixas ("1 item", "2 items" como strings separadas)
- Usar a sintaxe de plural do framework escolhido, não condicionais manuais no código
- Incluir sempre a categoria `other` como fallback, mesmo para línguas que não a usam para todos os números
- Testar com valores que expõem as categorias menos óbvias: 0, 1, 2, 5, 11, 21, 100
Um arquivo preparado com essas categorias desde a origem poupa o tradutor do trabalho de pedir esclarecimentos sobre cada string numérica, e evita que a equipe de engenharia tenha que reabrir o código depois da localização.
Variáveis, contexto e tamanho de texto
Placeholders sem contexto são a segunda causa mais comum de erros de localização, depois dos plurais mal preparados. `{0}` ou `{1}` não dizem nada ao tradutor sobre o que vai entrar ali. É nome de usuário, é uma data, é um valor monetário? Nomear os placeholders de forma descritiva (`{userName}`, `{orderDate}`, `{totalAmount}`) resolve a maior parte da ambiguidade sem custo adicional de engenharia.
Comentários de contexto no próprio arquivo de recursos fazem a diferença entre uma tradução correta na primeira tentativa e uma que volta para revisão. Um comentário simples como `// Botão principal da tela de checkout, máximo de 20 caracteres` dá ao tradutor duas informações críticas: onde a string aparece e que limite de espaço precisa respeitar.
Isso importa particularmente em interfaces mobile, onde o espaço é limitado e o alemão ou o finlandês podem precisar de 30% mais caracteres do que o inglês para dizer a mesma coisa. Equipes que localizam aplicativos para mercados como Angola ou Moçambique enfrentam ainda a variável do suporte offline e da qualidade de rede, que pode exigir estratégias diferentes de carregamento de recursos linguísticos. O artigo sobre localização de aplicativos mobile para Angola e Moçambique detalha essas condições específicas.
Formato de arquivo e fluxo de trabalho
O formato técnico escolhido para exportar as strings influencia diretamente a qualidade e a velocidade da localização. Os mais comuns:
| Formato | Uso típico | Observação |
|---|---|---|
| JSON | Apps web, React, Vue | Fácil de automatizar, sem suporte nativo a comentários |
| .resx | Aplicações .NET | Suporta comentários e metadados por string |
| .po / .pot | Projetos gettext, WordPress | Padrão maduro, boa integração com ferramentas CAT |
| XLIFF | Troca entre sistemas de tradução | Formato de intercâmbio recomendado para equipes com fornecedor externo |
| ARB | Flutter | Suporta plurais ICU nativamente |
Para projetos com fornecedor de tradução externo, o XLIFF continua sendo a opção mais segura: preserva o contexto, os comentários e os placeholders sem exigir que o tradutor edite código-fonte diretamente. Isso reduz o risco de alguém, por engano, apagar uma chave ou alterar um placeholder que o motor da aplicação espera encontrar intacto.
Equipes que trabalham com plataformas SaaS e ciclos de lançamento contínuos se beneficiam de automatizar essa exportação, de forma que cada nova string criada pelos desenvolvedores entre no fluxo de localização sem intervenção manual. O artigo sobre localização ISO 17100 para plataformas SaaS explica como estruturar esse fluxo com controle de qualidade auditável.
Como a M21Global trata arquivos de software
A M21Global trabalha com os formatos de arquivo mais comuns em projetos de localização de software, incluindo JSON, .resx, .po e XLIFF, preservando placeholders, categorias de plural CLDR e comentários de contexto durante todo o processo. Para interfaces e documentação técnica associada a produtos de software, a solução se adequa ao volume e à criticidade do conteúdo: desde catálogos de ajuda com tradução assistida por IA até strings de interface que exigem revisão humana completa.
Para equipes que estão preparando o primeiro ciclo de localização ou migrando de um fluxo manual para um processo estruturado, a M21Global ajuda a definir o formato de exportação e as convenções de nomenclatura antes do primeiro envio de arquivos. Consulte os serviços de tradução e localização de software e peça uma avaliação técnica do seu projeto.
Serviços Relacionados
Peça um orçamento gratuito de localização de software
- Peça um orçamento gratuito de localização de software
- Localizacao Aplicacao Movel Angola Mocambique
- Localizacao Iso 17100 Para Plataformas Saas
Perguntas Frequentes
O que é o CLDR e por que ele importa na localização de software?
O CLDR (Common Locale Data Repository) é o padrão do Unicode Consortium que define as categorias de plural, formatos de data e número para cada língua. Preparar o arquivo de recursos com as categorias CLDR corretas evita plurais gramaticalmente errados em línguas como o polonês, o russo ou o árabe.
Qual o melhor formato de arquivo para enviar strings a um fornecedor de tradução?
O XLIFF geralmente é a opção mais segura para troca com fornecedores externos, porque preserva contexto, comentários e placeholders sem exigir edição direta de código-fonte.
Por que concatenar strings no código é um problema de localização?
Concatenar texto fixo com variáveis assume uma ordem de palavras que não existe em todas as línguas. Usar strings completas com placeholders nomeados permite ao tradutor reordenar os elementos conforme a gramática do idioma de destino.
Quantas formas de plural preciso suportar num projeto multilíngue?
Depende das línguas de destino: o inglês tem duas, o português tem duas com concordância de gênero, o polonês tem quatro e o árabe tem seis. O arquivo de recursos deve seguir as categorias CLDR da língua em questão, não assumir o padrão do inglês.
