Uma string com género codificado no texto inglês parte-se assim que chega ao português. "You have 1 new message" vira plural gramatical em quase todas as línguas latinas, e um ficheiro de recursos mal preparado obriga o tradutor a adivinhar se "1" é singular ou se o sistema vai mesmo mostrar "1 mensagens" ao utilizador final. Isto não é um detalhe de estilo. É um bug de localização que chega a produção.
Este artigo cobre o que separa um ficheiro de recursos pronto a 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 equipas que localizam pela primeira vez é concatenar strings no código. `"O utilizador " + 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 lê da direita para a esquerda. Nenhuma destas 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 utilizador {userName} tem {messageCount} mensagens"`. Isto permite ao tradutor reordenar os elementos conforme a gramática da língua de destino, sem tocar na lógica do código. Frameworks como ICU MessageFormat, Fluent (Mozilla) ou os ficheiros .resx do .NET já suportam este 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 perceber 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 polaco tem quatro formas plurais diferentes consoante o número termine em 1, em 2-4, ou noutro dígito. O árabe tem seis categorias gramaticais de plural. Um ficheiro de recursos preparado apenas com `one` e `other` parte assim que o projeto precisa de suportar russo ou árabe.
O standard 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 estas categorias. A preparação correta do ficheiro 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 ficheiro preparado com estas categorias desde a origem poupa ao tradutor o trabalho de pedir esclarecimentos sobre cada string numérica, e evita que a equipa de engenharia tenha de reabrir o código depois da localização.
Variáveis, contexto e comprimento 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 lá entrar. É nome de utilizador, é 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 ficheiro de recursos fazem a diferença entre uma tradução correta à primeira e uma que volta para revisão. Um comentário simples como `// Botão principal do ecrã de checkout, máximo 20 caracteres` dá ao tradutor duas informações críticas: onde a string aparece e que limite de espaço tem de respeitar.
Isto importa particularmente em interfaces móveis, 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. Equipas que localizam aplicações 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 aplicações móveis para Angola e Moçambique detalha estas condições específicas.
Formato de ficheiro 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 | Standard maduro, boa integração com ferramentas CAT |
| XLIFF | Troca entre sistemas de tradução | Formato de intercâmbio recomendado para equipas com fornecedor externo |
| ARB | Flutter | Suporta plurais ICU nativamente |
Para projetos com fornecedor de tradução externo, o XLIFF continua a ser a opção mais segura: preserva o contexto, os comentários e os placeholders sem exigir que o tradutor edite código-fonte diretamente. Isto reduz o risco de alguém, por engano, apagar uma chave ou alterar um placeholder que o motor da aplicação espera encontrar intacto.
Equipas que trabalham com plataformas SaaS e ciclos de lançamento contínuos beneficiam de automatizar esta exportação, de forma a que cada nova string criada pelos programadores 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 controlo de qualidade auditável.
Como a M21Global trata ficheiros de software
A M21Global trabalha com os formatos de ficheiro 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 adequa-se 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 equipas que preparam o primeiro ciclo de localização ou que estão a migrar 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 ficheiros. 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
- Uma Surpreendente Quantidade De Conteudo Disponivel Online E Gerada Por Inteligencia Artificial
Perguntas Frequentes
O que é o CLDR e porque importa na localização de software?
O CLDR (Common Locale Data Repository) é o standard do Unicode Consortium que define as categorias de plural, formatos de data e número para cada língua. Preparar o ficheiro de recursos com as categorias CLDR corretas evita plurais gramaticalmente errados em línguas como o polaco, o russo ou o árabe.
Qual o melhor formato de ficheiro 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.
Porque é 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 de suportar num projeto multilingue?
Depende das línguas de destino: o inglês tem duas, o português tem duas com concordância de género, o polaco tem quatro e o árabe tem seis. O ficheiro de recursos deve seguir as categorias CLDR da língua em causa, não assumir o padrão do inglês.
