Todas as empresas com quem falamos esbarram nas mesmas duas barreiras.
A primeira é a taxa de coordenação da consistência.
A sua app Android é desenvolvida por uma equipa. A sua app web, por outra. O seu site de marketing, a sua documentação, as suas ferramentas internas — cada um pertence a uma equipa diferente, cada um com a sua própria cadência de lançamentos, os seus próprios revisores, o seu próprio pipeline de entrega.
As ferramentas legacy podem partilhar memória de tradução e glossários entre projetos. Existem workspaces. Existem recursos ao nível da organização. Mas partilhar não é o mesmo que impor. Um termo num glossário partilhado é uma sugestão para o tradutor, não uma restrição para o modelo. A consistência entre equipas passa a ser uma disciplina. Alguém mantém o glossário alinhado. Alguém resolve os conflitos de terminologia entre equipas. Alguém anda atrás da equipa que traduz uma call to action de uma forma enquanto outra a publica de outra. A consistência é possível. A manutenção é contínua.
Dentro do projeto de cada equipa, o desvio agrava-se ainda mais. A memória de tradução mantém a consistência enquanto os segmentos não mudarem. Numa base de código que é refatorizada todas as semanas, os segmentos mudam todas as semanas. A nossa investigação RAL mede a rapidez com que a terminologia deriva quando o modelo não tem contexto recuperado.
A segunda barreira é o custo de alguma vez abandonar as ferramentas que geram essa taxa. Numa empresa, cada dimensão se multiplica — glossários acumulados entre equipas, memória de tradução acumulada em TMX e em formatos proprietários dos fornecedores, conectores ligados ao CI de cada equipa, listas de tradutores negociadas via procurement, SSO integrado com o IdP.
A migração parece um programa de engenharia de vários trimestres que nenhum gestor de localização quer assumir.
Há duas arquiteturas que se ajustam à realidade de várias equipas.
Uma substitui a memória de tradução ao nível do projeto por um motor de localização à escala da organização que recupera contexto no momento da inferência. Um glossário, uma voz da marca: a app de cada equipa vai buscar tudo ao mesmo motor de localização.
A outra substitui a migração feita pelo cliente por um engenheiro de localização forward-deployed da Lingo.dev, que faz a migração no nosso tempo, não no seu.
Ambos os modelos já sustentam todas as outras peças de infraestrutura da sua stack — agora, queremos que a localização finalmente acompanhe.
Arquitetura #1: o motor de localização#
Motor de localização
Uma API de tradução com estado que as equipas criam na Lingo.dev, configurada por organização. Cada motor de localização mantém o seu próprio glossário, voz da marca, instruções específicas por idioma e uma cadeia de modelos ordenada. Cada pedido recupera os termos de glossário correspondentes, injeta-os na janela de contexto do modelo antes de ser gerado o primeiro token e é avaliado de forma independente após a conclusão. A primeira tradução beneficia de zero contexto; a milésima beneficia de tudo.
Um motor de localização mantém a consistência ao nível do termo, não ao nível do segmento. Está definido à escala da sua organização, não do projeto de uma única equipa. Um glossário, uma voz da marca: cada superfície de cada equipa vai buscar tudo ao mesmo motor de localização.
Uma entrada de glossário para "Submit" é acionada em todas as superfícies em espanhol — botão, assunto de email, tooltip. Seja a equipa web ou a equipa mobile, não faz diferença. A recuperação faz correspondência pelo significado, não pelas strings. Uma entrada para "Deploy" é acionada em "deploying", "deployment", "Deploy your app" — sem precisar de uma entrada separada para cada forma.
Uma voz da marca é associada ao motor de localização por idioma. Todos os pedidos a utilizam.
As instruções são regras discretas, testáveis e definidas por idioma. Convenções de abreviaturas, espaços inseparáveis, aspas — cada uma pode ser depurada de forma autónoma.
Uma cadeia de modelos encaminha cada pedido para o modelo principal, com alternativas de recurso ordenadas. Troque de fornecedor sem mexer no glossário.
Um avaliador de IA corre num modelo independente. Atribui uma pontuação a cada pedido face ao glossário e a cada instrução em separado. Aprovação/reprovação com fundamentação, acompanhada em série temporal.
| Preocupação | Ferramentas ao nível do projeto | Motor de localização à escala da organização |
|---|---|---|
| Âmbito da consistência | Por projeto, por equipa | Por organização |
| Unidade de consistência | Segmento completo, indexado por hash | Termo individual, correspondido semanticamente |
| Sobrevive a reescritas da origem | Não | Sim |
| Entre apps, entre equipas | Disciplina; as pessoas mantêm tudo alinhado | Arquitetural; o motor de localização mantém tudo alinhado |
| Medição da qualidade | Verificações baseadas em regras (tags, números) | Pontuação LLM por pedido |
| Flexibilidade do modelo | Dependência do fornecedor | Cadeia ordenada |
| Autoridade sobre o resultado | Critério do tradutor | O glossário sobrepõe-se ao modelo |
O desvio passa a ser uma condição que pode medir, não uma condição que tem de absorver. O glossário é acionado em todos os pedidos. O avaliador de IA verifica a conformidade em cada pedido.
O mecanismo tem nome: retrieval augmented localization (RAL). No momento da inferência, o motor decompõe a entrada em frases n-gram, gera embeddings e executa pesquisa por similaridade de cosseno no índice vetorial do glossário. Os termos correspondentes entram na janela de contexto do modelo antes de ser gerado o primeiro token. Estruturalmente idêntico a RAG, aplicado à tradução.
Numa avaliação controlada, em vários fornecedores de LLM e várias línguas europeias, RAL reduziu os erros terminológicos em 17–45%. Mais de 42.000 avaliações de qualidade emparelhadas. p corrigido por Holm-Bonferroni < 0,001 em todos os fornecedores. As pontuações holísticas de qualidade não conseguiram detetar a diferença.
Arquitetura #2: engenharia de localização forward-deployed#
A segunda barreira é a migração. Tem uma stack funcional. Produz a taxa, mas funciona. O custo de a substituir — tempo de engenharia, retrabalho de integração, novo onboarding de tradutores, migração de dados históricos — excede de forma consistente o custo de continuar a pagar a taxa.
É por isso que a taxa continua a ser paga. Depois de vermos o mesmo bloqueio de migração travar empresas sérias vezes sem conta, decidimos absorver nós próprios a migração.
Quando a Lingo.dev faz o onboarding de uma empresa, os nossos engenheiros fazem a migração. Não como um contrato de serviços profissionais acrescentado à licença. Como o percurso de onboarding por defeito.
Um engenheiro de localização forward-deployed lê o seu glossário, os seus documentos de voz da marca, a configuração dos seus conectores, os seus contratos com tradutores. Importa a sua memória de tradução a partir de TMX e o seu glossário a partir de qualquer formato legacy em que esteja. Nada é reconstituído. Constrói o motor de localização na Lingo.dev com a sua terminologia pré-carregada. Liga-o ao seu CI. Encaminha a sua lista de tradutores pelo pipeline assíncrono para que as pessoas em quem confia continuem no circuito.
É no cenário com várias equipas que a arquitetura compensa. Na versão legacy, alinhar terminologia entre equipas significa N migrações sincronizadas — cada equipa a reconstituir chaves e TM dentro do seu próprio projeto. Aqui, o motor de localização é construído uma vez. Cada equipa liga a sua app a esse motor ao seu próprio ritmo. A consistência entre apps aparece no primeiro idioma que chega ao motor, não depois de cada equipa concluir a sua própria migração.
Os nossos engenheiros acompanham-no até à sua próxima implementação em produção, e à seguinte, até a sua equipa interna assumir o sistema.
É assim que fazemos o onboarding de clientes empresariais.
Quando uma organização com várias equipas já está a fazer entregas todas as semanas, a tradução não pode ser um ticket de procurement entre comprador e fornecedor. Tem de correr a par da sua próxima implementação em produção, não depois dela. A engenharia forward-deployed é a forma como a Palantir, a Scale AI, a Ramp e outros fornecedores de infraestrutura fazem o onboarding de clientes empresariais há mais de uma década.
Agora, queremos que a localização finalmente acompanhe.
Auditoria
Um engenheiro da Lingo.dev analisa os seus repositórios de origem, a sua TM existente (incluindo exportações TMX), o seu glossário, os seus conectores e os seus contratos com tradutores — em todas as equipas responsáveis por uma superfície. Produz um plano de migração com ordem e calendário. O plano é seu.
Motor criado para igualar a sua qualidade atual
Configuramos o motor de localização com o seu glossário importado, a sua voz da marca por idioma e o seu pipeline de tradutores. Antes de qualquer tráfego de produção, executamos uma comparação lado a lado — o resultado da sua ferramenta atual versus o resultado do motor, mesmas strings, mesma semana. Decide se a qualidade se mantém.
Ligado ao CI de cada equipa
Sem rip-and-replace. O motor de localização funciona como uma etapa no pipeline existente de cada equipa. Fluxos de merge, fluxos de revisão, revisores — tudo fica na mesma. O motor substitui a etapa antiga.
Transição ao seu ritmo
Primeiro uma equipa, um par de idiomas. Depois três. Depois o resto. Escolhe a ordem. Executamos a comparação em cada etapa. O rollback faz-se com um único commit.
Transferência para a sua equipa
O nosso engenheiro passa o sistema para a sua equipa de plataforma — documentação, runbooks e uma rotação de on-call que asseguramos até assumirem.
Evidência#
Investigação. O estudo RAL: mais de 42.000 avaliações de qualidade emparelhadas em vários fornecedores de LLM e várias línguas europeias. p corrigido por Holm-Bonferroni < 0,001 em todos os fornecedores. A redução de erros terminológicos variou entre 17% e 45%.
Configuração acima da escolha do modelo. Descobrimos que, entre Mistral, Gemini, Claude, GPT — qualquer modelo + um bom glossário, voz da marca e configuração de contexto produz, de forma consistente, traduções prontas a publicar, com qualidade de referência, por uma fração do custo. Não porque tenhamos melhorado o modelo. Em cada pedido, o motor de localização recupera, por pesquisa de similaridade, os termos do glossário, a voz da marca e as instruções do idioma correspondentes, e injeta-os na janela de contexto do modelo antes de ser gerado o primeiro token.
Escala de produção. Mais de 200 milhões de palavras traduzidas na plataforma.
Clientes identificados. Mistral, Solana, SoSafe, Cal.com.
Âmbito#
A Lingo.dev serve equipas de localização de todos os tipos — empresas com um único produto, projetos open-source, equipas exclusivamente mobile, plataformas empresariais. A arquitetura aqui descrita foi afinada para empresas com várias equipas a lançar várias aplicações em mais de 20 idiomas.
O que acontece a seguir#
O primeiro passo é um piloto de duas semanas. Uma equipa, um par de idiomas.
Um engenheiro de localização destacado para o terreno trabalha lado a lado com o responsável pela localização e com a liderança de engenharia. Estudamos o seu workflow. Implementamos um sistema de medição para que possa ver a qualidade das traduções em idiomas que a sua equipa não domina — avaliadores de IA em modelos independentes, a avaliar cada tradução com base no seu glossário e nas suas regras. A avaliação é adaptada do MQM, o modelo-padrão de avaliação da qualidade da tradução.
Construímos o motor de localização com base no seu glossário e nos seus documentos de voz da marca. Executamo-lo sobre o seu conteúdo de origem, lado a lado com a sua ferramenta atual. Vê a diferença e decide.
A partir daí, planeamos a migração das restantes equipas e idiomas ao seu ritmo, não ao nosso.
Fale hoje com os nossos especialistas em engenharia de localização.
