Localização de Software e Aplicativos

JSON puro não tem comentários e não tem suporte a plurais — funciona bem para inglês, mas é frágil em produção quando tradutores adicionam apóstrofos curvos (' vs '), espaços não separáveis estreitos em torno da pontuação francesa, ou aspas alemãs (», «). Um tradutor francês que escreve o correto L'application com um apóstrofo tipográfico passará no QA linguístico e quebrará um parser JSON frágil. Normalizamos apóstrofos na importação, validamos a presença de UTF-8 BOM e executamos uma passagem de sintaxe antes de qualquer locale ser enviado.

O Android armazena apóstrofos como \' e ampersands como &. Tradutores rotineiramente colam caracteres curvos do Microsoft Word que parecem idênticos e enviam — até que o layout renderize mojibake em tempo de execução. Usamos um round-trip XLIFF personalizado para assets Android, para que o tradutor nunca veja o XML bruto, e re-escapamos na exportação.

O problema clássico são as regras de plural. O iOS usa as categorias plurais CLDR (zero, one, two, few, many, other) através do .stringsdict. Um tradutor ingênuo tratará o arquivo como um-para-um e perderá variantes plurais — seu app em alemão então dirá "1 Nachrichten". Usamos um editor com reconhecimento de plurais que expõe cada categoria CLDR conforme necessário para o locale de destino e recusa a exportação se alguma categoria estiver faltando.

O .resx aceita comentários XML e referências de código incorporadas; .properties usa ISO-8859-1 por padrão (toolchains modernos suportam UTF-8, mas a combinação errada ainda envia escapes \uXXXX que frustram os tradutores). Forçamos UTF-8 na importação e emitimos escapes nativos apenas no momento do build.

Sempre que possível, extraímos arquivos de origem para XLIFF 1.2 ou 2.0, traduzimos dentro do nosso editor com contexto anexado e re-mesclamos. Isso permite que os tradutores vejam o comentário de origem, a captura de tela e a restrição (limite de caracteres, forma plural ICU, flag de espelhamento RTL) sem nunca tocar no arquivo de origem. O pipeline de build mescla de volta ao formato que seus desenvolvedores commitaram.

{count, plural,
 one {# friend}
 few {# friends}
 many {# friends}
 other {# friends}
}

Isso funciona bem em inglês, francês e alemão. Em árabe você precisa de zero, one, two, few, many, other. Em polonês, few cobre 2-4 apenas quando o último dígito é 2-4 e o número não é 12-14 — o polonês tem aproximadamente 5 categorias plurais. O galês tem a sua própria. Traduzimos de acordo com o conjunto de regras plurais CLDR para cada locale, não de acordo com o template em inglês.

Espanhol, italiano e pashto precisam saber se o sujeito é masculino, feminino ou neutro para flexionar o verbo. Uma tradução ingênua de "You are invited" padrão para masculino; uma usuária feminina vê gramática incorreta em 50% dos locales. O select do ICU lida com isso:

{gender, select,
 female {Estás invitada}
 male {Estás invitado}
 other {Te han invitado}
}

Se seu modelo de dados não rastreia gênero, o caminho seguro é a ramificação neutra other. Sinalizamos strings com gênero na revisão de origem para que sua equipe possa decidir se captura gênero, padrão para neutro ou envia variantes — antes que o orçamento de tradução seja comprometido.

Avaliações na App Store e no Google Play rotineiramente apontam plurais incorretos: "App está com bugs, diz '1 mensagens'". Avaliações de uma estrela se acumulam e rebaixam o ranking. Corrigir plurais após o lançamento custa mais do que tradução com reconhecimento de ICU antecipadamente.

O bug de produção mais comum: desenvolvedores escrevem margin-left: 16px em vez de margin-inline-start: 16px. Em um locale da esquerda para a direita, eles são idênticos. Em árabe, o primeiro fixa a margem à esquerda da tela; o segundo inverte corretamente para a direita. Auditamos sua folha de estilos em busca de propriedades físicas (left, right, padding-left, border-right) antes de tocarmos nas strings.

Um parágrafo em árabe que menciona um nome de marca em inglês, uma URL ou um numeral torna-se uma string de direção mista. Os navegadores lidam com isso usando o Algoritmo Bidirecional Unicode, mas o algoritmo é heurístico e erra em casos previsíveis — mais frequentemente quando uma frase termina com um número ou pontuação latina. Inserimos marcas U+202A/U+202C (LRE/PDF) ou usamos tags <bdi> em torno de tokens opacos como nomes de usuário e IDs de produto.

Ícones de seta, o chevron de "voltar", desfazer e refazer, direções de controle deslizante, barras de progresso — cada ícone direcional precisa de uma variante RTL ou uma transformação CSS. Lucide e Heroicons têm variantes com reconhecimento RTL; o conjunto de ícones do Material requer uma classe de espelhamento. Catalogamos cada ícone direcional em seu design system e sinalizamos qualquer um que não esteja espelhado na auditoria.

Pilhas de fontes ocidentais rotineiramente carecem de glifos árabes — Helvetica Neue, Inter e Roboto todos precisam de um fallback árabe. O padrão do sistema (Geeza Pro no iOS, Noto Naskh Arabic no Android) renderiza, mas a altura da linha está errada e o kerning é ruim. Testamos a renderização nos dispositivos reais que seus usuários têm — não apenas Chrome no macOS — e sinalizamos correções de pilha de fontes como parte da revisão de pseudo-locale.

O árabe é nosso maior par de idiomas único. Nossa marca irmã arabictranslation.co.uk envia localização em árabe desde 2012. As sobretaxas RTL que a maioria das agências do Reino Unido adiciona (20-30%) refletem que este é um trabalho incomum para elas; é o trabalho que mais fazemos. Não cobramos sobretaxa RTL.

Adequado para a maioria das equipes SaaS. Um webhook do GitHub dispara a cada push para main. Nosso serviço inspeciona o diff em busca de strings novas ou alteradas, elabora os locales, envia-os a um linguista para revisão e abre um PR de retorno. A proteção de ramificação garante que o PR não possa ser mesclado antes da revisão. Tempo típico de ponta a ponta: 18-24 horas para 35 idiomas em um commit de 200 strings.

Se sua equipe prefere que as mudanças de locale fluam através do seu sistema de build (CircleCI, GitHub Actions, GitLab Runners), expomos uma CLI: lingosecure pull puxa as traduções mais recentes para seu repositório como uma etapa de build, lingosecure push carrega quaisquer mudanças de string de origem para tradução. Usado por equipes que executam release trains e não querem PRs de tradução em seu fluxo.

Se você já tem um TMS, temos prazer em atuar como a camada de linguista dentro dele — seus desenvolvedores continuam a enviar strings para o TMS, nossos linguistas traduzem dentro do TMS e a sincronização do TMS é executada como sempre foi. Zero mudança no fluxo de trabalho para seus engenheiros. O benefício: um fornecedor em vez de costurar uma assinatura TMS, uma lista de freelancers e um fornecedor para as coisas regulamentadas.

Todos os três padrões compartilham um princípio: sua memória de tradução é sua. Cada segmento traduzido é registrado em sua TM, que hospedamos dentro do LingoSecure ou exportamos para seu TMS sob demanda. Se você trocar de fornecedor no próximo ano, a TM vai com você. Não há lock-in.

Fixamos a memória de tradução por versão à release do produto. Seu v4.2 nunca enviará acidentalmente strings traduzidas do v4.1. Se sua equipe precisar reverter uma release, a TM reverte com ela. Isso importa para produtos regulamentados onde uma divulgação traduzida deve corresponder à versão em inglês contra a qual foi aprovada.

• Truncamento — botões que cabem "OK" mas não "Aceptar"
• Strings codificadas no código — qualquer coisa não envolvida em t
• Bugs de concatenação — "Hello " + username quebrará em idiomas com ordem de palavras diferente
• Suposições de largura fixa — seletores de data, dropdowns, abas de navegação
• Fallbacks de fonte — texto que se transforma em retângulos porque a fonte não cobre Latin Extended-A
• Bugs de inversão RTL — cada ícone direcional e layout inverte em pseudo-RTL

Entregamos o build de pseudo-locale como uma implantação Storybook ou uma ramificação de recurso contra a qual sua equipe de QA pode testar. O log de defeitos vai direto para seu Linear, Jira ou GitHub Issues. Corrigimos os problemas do lado do locale; sua equipe corrige os do lado do produto, antes de pagar por uma única palavra de tradução humana.

Para produtos maduros, executamos uma passagem adicional: cada tela é capturada em inglês, pseudo-EN, alemão, árabe e chinês, e os diffs são comparados. Regressões de layout aparecem imediatamente. O mesmo fluxo de trabalho é executado contra cada PR se você quiser como uma GitHub Action.

Cada string passa sob um linguista qualificado antes de sair do portal. Usamos linguistas especializados para acelerar o primeiro rascunho, mas nenhuma string jamais é enviada sem aprovação humana. Se você quer MT bruto por razões de custo, AWS Translate e nosso pipeline API são excelentes — ajudaremos você a configurá-los, mas não colocaremos nosso nome no resultado.

Uma correção de emergência de 50 strings em 4 horas é realista na maioria dos principais locales. Um lançamento de produto de 5.000 strings em 24 horas não é realista e não nos comprometeremos com isso. Agendamos de trás para frente a partir da sua data de lançamento com buffer de QA embutido; se seu cronograma for mais curto, diremos o que é realmente alcançável.

A maioria das agências do Reino Unido roteia árabe para um estúdio no Cairo ou Beirute. Traduzimos internamente com linguistas nomeados. A mesma pessoa que traduziu suas strings v1 é a pessoa que traduz v4.7. Consistência terminológica é função de continuidade; continuidade requer não subcontratar.