Strings de interface e revisão de i18n

Uma palavra, dez jeitos de quebrar

Uma string de interface é o tipo de texto mais difícil de traduzir bem, por razões que não têm nada a ver com vocabulário. Ela é curta, então não há frase ao redor para desambiguá-la. Vive dentro de um layout, então tem um comprimento máximo que ninguém anotou. E muitas vezes carrega código — placeholders, variáveis, regras de plural — que precisa atravessar a tradução byte a byte.

Essa combinação produz uma família específica de bugs: o rótulo em alemão que transborda do botão, o placeholder {username} que um tradutor “traduziu”, a string de plural que se lê certa para 2 itens e errada para 5, o botão “Back” traduzido como parte do corpo. Cada um é pequeno. Juntos, fazem o produto parecer quebrado em todos os mercados ao mesmo tempo.

O que conferimos, string por string

Nosso grupo de prática de software traduz e revisa strings de interface com base em uma checklist construída a partir desses modos de falha:

• Proteção de placeholders e variáveis — {count}, %s, %(name)s e a sintaxe ICU travados como tokens intocáveis e depois verificados por máquina contra o original em cada string de destino
• Regras de plural por idioma — cada forma de plural exigida traduzida, com a sintaxe ICU validada, para que as contagens renderizem corretamente do zero em diante
• Comprimento e truncamento — alemão e francês ficam cerca de 30% mais longos que o inglês; as strings são conferidas contra os limites de caracteres quando você os fornece, e sinalizadas quando não fornece
• Verificação de contexto — os tradutores trabalham com capturas de tela, descrições das strings ou um build de staging, e strings ambíguas voltam como perguntas, não como palpites
• Consistência terminológica — uma base terminológica por idioma, para que o rótulo do botão coincida com a documentação, os tooltips e o site de marketing

Cada idioma é tratado por um revisor nativo com experiência em software. Verificações automatizadas capturam o que as máquinas capturam bem; um humano decide o que vai ao ar.

Pseudolocalização: encontre a quebra antes de pagar por ela

A pseudolocalização é o investimento em i18n mais barato que você pode fazer. Antes de qualquer tradução real começar, suas strings em inglês são substituídas por texto artificialmente expandido e acentuado — “Settings” vira algo como [Šéttîñgš one two] — e o app é executado como se aquele fosse um locale real.

O build mostra imediatamente três coisas: layouts que quebram com 30% de expansão de texto, strings hardcoded no código-fonte em vez de externalizadas em arquivos de recursos, e caracteres que as suas fontes ou a sua codificação tratam mal. Consertar isso antes da tradução significa consertar uma vez — não uma vez por idioma depois que as traduções voltam.

Auditando o que você já lançou

Se o seu produto já está localizado, revisamos em vez de retraduzir. Um revisor nativo percorre a sua interface em contexto — telas reais, não planilhas — e devolve uma lista priorizada: erros genuínos de tradução primeiro, truncamentos e variáveis quebradas em seguida, questões de tom e consistência por último. Você conserta o que importa e dispensa uma retradução completa de que provavelmente não precisa.

Como todo projeto da Link Translation, começa com um orçamento fechado em até 24 horas. Envie seus arquivos de strings e, se tiver, capturas de tela ou um build de teste — quanto mais contexto, menos palpites alguém precisa dar.