Localização de software e aplicativos

A localização de software parece simples até você colocá-la no ar. Uma equipe escreve en.json e supõe que espanhol, alemão e árabe seguirão o mesmo caminho. Mas não seguirão. Cada formato de arquivo tem uma peculiaridade que quebra o build de uma agência despreparada. Após 14 anos e vários milhares de lançamentos SaaS, temos uma lista curta dos casos que pegam até equipes de engenharia maduras.

JSON, YAML e o problema do apóstrofo

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.

Android strings.xml: o escape silencioso

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.

iOS .strings e .stringsdict

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.

.NET .resx e Java .properties

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.

O round trip XLIFF

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.

Se seu produto tem uma tagline como "Maria convidou 3 amigos para o seu evento", você está prestes a descobrir o ICU MessageFormat. O inglês precisa de três variáveis. O russo precisa de quatro formas plurais (1, 2-4, 5+, fracionário). O árabe precisa de seis. O polonês tem regras diferentes novamente. Muitos produtos enviam com uma string plana como {name} invited {count} friends e aceitam silenciosamente gramática incorreta em 80% dos locales.

O padrão correto

{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.

Sujeitos de gênero

Espanhol, italiano e russo 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.

Por que isso importa para SEO e confiança

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.

Da direita para a esquerda é a categoria mais quebrada na localização de software. Temos 14 anos de árabe - é nosso maior par - e ainda vemos produtos SaaS polidos serem lançados com erros de dois caracteres que tornam a interface inutilizável no MENA. A lista abaixo é de auditorias reais que executamos para clientes antes de eles nos contratarem.

Propriedades CSS lógicas

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.

Texto bidirecional dentro de parágrafos

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 que têm uma direção

Í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.

Fontes e renderização

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.

Por que este é nosso campo de jogo

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.

Se sua equipe de engenharia envia inglês toda terça-feira, seu alemão, francês e árabe também deveriam ser enviados toda terça-feira. Qualquer outra coisa é um problema de coordenação de release disfarçado de problema de tradução. Há três padrões de integração que suportamos; o correto depende de como seu repositório está estruturado.

Padrão 1: Fluxo de trabalho de PR acionado por webhook

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.

Padrão 2: Etapa de CI em seu build

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.

Padrão 3: Sincronização TMS (Phrase / Lokalise / Crowdin)

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.

Memória de tradução e base de termos

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.

Versionamento e rollback

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.

Antes de enviarmos uma string a um tradutor, executamos seu produto através de um build de pseudo-locale. Cada string em inglês é envolvida em acentos e preenchida em 30%: "Submit" torna-se "[Ŝûbmît⏎ⓅⒶⒹ]". O objetivo não é testar a qualidade da tradução; é testar seu produto. O preenchimento simula a expansão de 30-40% do alemão; os acentos forçam um caminho de renderização Unicode; os colchetes expõem strings concatenadas (um fragmento em inglês codificado no código aparecerá sem envolvimento).

O que o pseudo-locale detecta

• 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.

QA visual com diffing de captura de tela

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.

Os testes de pseudo-locale detectam o que quebra antes da tradução; o LQA detecta o que quebra depois. Depois que as strings traduzidas são integradas, um testador nativo percorre a build real (não uma planilha) em dispositivos reais: cada tela, cada caixa de diálogo, cada estado vazio e cada mensagem de erro, no idioma em teste. Defeitos linguísticos (um composto alemão truncado, um formato de data que ninguém localizou, uma string que funciona isolada mas fica errada ao lado do botão em que aparece) são registrados junto com os funcionais (formulários que rejeitam caracteres não latinos, links que dão erro 404 na build localizada, layouts que se desfazem em RTL).

Como funciona a etapa de testes

• Revisão linguística em contexto - um linguista nativo revisa cada string renderizada na interface, onde as limitações de espaço e os conflitos de sentido ficam realmente visíveis
• Verificações funcionais por locale - navegação, formulários, checkout e fluxos de conta testados em cada idioma de destino no iOS, no Android e em navegadores de desktop
• Defeitos registrados onde a sua equipe trabalha - Linear, Jira ou GitHub Issues, com captura de tela, locale, dispositivo e gravidade em cada ticket; nós corrigimos os problemas do lado do locale e a sua equipe corrige os do lado do produto
• Cadência compatível com sprints - o LQA funciona como uma etapa do seu pipeline de lançamentos, e não como uma auditoria pontual, a £40-£60 por hora ou com escopo por lançamento

A mesma etapa cobre jogos. Diálogos ramificados, textos de missões, bancos de dados de itens e páginas nas lojas são testados dentro da build real sob NDA, com o mesmo fluxo de defeitos, e isso importa ainda mais nesse caso, porque os jogadores tiram prints das traduções ruins e esses prints sobrevivem ao patch que as corrige. O LQA de jogos em EFIGS, CJK, português do Brasil, russo e árabe passa pela mesma equipe especializada.

A maioria das equipes SaaS escolhe entre três caminhos para localização. Nenhum deles está errado; cada um tem um custo que queremos ser explícitos sobre, porque escolher o errado é o erro mais caro neste espaço.

A escolha certa depende do seu estágio. SaaS em estágio inicial com 3-5 mercados obtém o máximo do LingoSecure e um retainer mensal fixo. Series-B e posteriores com 12+ idiomas geralmente mantêm seu TMS existente e nos usam como camada de linguista. Plataformas regulamentadas com auditorias de conformidade querem o portal LingoSecure e a trilha de auditoria por segmento. Diremos honestamente qual caminho se encaixa.

Escopar com honestidade importa mais do que pitching agressivo. Há três coisas que nosso serviço de localização de software não faz, e preferimos ser claros antecipadamente do que prometer demais.

Não enviamos tradução automática não revisada

Cada string passa por um linguista qualificado antes de sair do portal. Nosso ambiente LingoSecure acelera o primeiro rascunho para que o tempo do linguista seja dedicado a nuances, terminologia e tom, mas nenhuma string jamais é enviada sem aprovação humana. Se você só quer saída de tradução automática não revisada por razões de custo, esse é outro serviço que não oferecemos; podemos indicar um fornecedor de MT pura se isso se encaixar no seu caso.

Não fazemos entrega no mesmo dia em volume empresarial

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.

Não subcontratamos árabe

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.