Toda empresa com quem conversamos bate nas mesmas duas paredes.
A primeira é o imposto de coordenação da consistência.
Seu app Android é desenvolvido por uma equipe. Seu app web, por outra. Seu site de marketing, sua documentação, suas ferramentas internas — cada um sob responsabilidade de uma equipe diferente, cada um com seu próprio ritmo de lançamentos, seus próprios revisores, seu próprio pipeline de entrega.
Ferramentas legadas conseguem compartilhar memória de tradução e glossários entre projetos. Workspaces existem. Recursos no nível da organização existem. Mas compartilhar não é o mesmo que impor. Um termo no glossário compartilhado é uma sugestão para o tradutor, não uma restrição para o modelo. A consistência entre equipes vira uma disciplina. Alguém mantém o glossário alinhado. Alguém resolve os conflitos de terminologia entre equipes. Alguém corre atrás da equipe que traduz um call-to-action de um jeito enquanto outra publica de outro. A consistência é possível. A manutenção é contínua.
Dentro do projeto de cada equipe, esse desvio só se agrava. A memória de tradução preserva a consistência enquanto os segmentos não mudam. Em uma base de código que é refatorada toda semana, os segmentos mudam toda semana. Nossa pesquisa de RAL mede a velocidade com que a terminologia se desvia quando o modelo não tem contexto recuperado.
A segunda parede é o custo de um dia conseguir sair das ferramentas que criam esse imposto. Em uma empresa, cada dimensão se multiplica — glossários acumulados entre equipes, memória de tradução construída em TMX e formatos proprietários de fornecedores ao longo de vários projetos, conectores ligados ao CI de cada equipe, listas de tradutores negociadas via compras, SSO integrado ao IdP.
A migração se apresenta como um programa de engenharia de vários trimestres que nenhum gerente de localização quer assumir.
Duas arquiteturas se encaixam nesse formato multi-equipes.
Uma substitui a memória de tradução com escopo de projeto por um engine de localização com escopo organizacional que recupera contexto em tempo de inferência. Um glossário, uma voz da marca, e o app de cada equipe puxa do mesmo engine 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.
Esses dois padrões já operam todas as outras partes da infraestrutura da sua stack — agora, queremos que a localização finalmente acompanhe.
Arquitetura nº 1: o engine de localização#
Engine de localização
Uma API de tradução com estado que as equipes criam na Lingo.dev, configurada por organização. Cada engine de localização persiste seu próprio glossário, voz da marca, instruções específicas por idioma e uma cadeia de modelos ranqueada. Cada solicitação recupera os termos correspondentes do glossário, injeta esses termos na janela de contexto do modelo antes de o primeiro token ser gerado e é avaliada de forma independente depois da conclusão. A primeira tradução se beneficia de contexto zero; a milésima se beneficia de tudo.
Um engine de localização mantém a consistência no nível do termo, não do segmento. Seu escopo é a organização inteira, não o projeto de uma equipe específica. Um glossário, uma voz da marca, e cada superfície de cada equipe puxa do mesmo engine de localização.
Uma entrada de glossário para "Submit" é acionada em toda superfície em espanhol — botão, assunto de e-mail, tooltip. Seja a equipe web ou mobile, não importa. A recuperação corresponde ao significado, não às 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 é vinculada ao engine de localização por idioma. Toda solicitação a utiliza.
Instruções são regras discretas e testáveis com escopo por idioma. Convenções de abreviação, espaços não separáveis, aspas — cada uma pode ser depurada por conta própria.
Uma cadeia de modelos encaminha cada solicitação para o modelo principal, com fallbacks ranqueados. Troque de provedor sem mexer no glossário.
Um avaliador de IA roda em um modelo independente. Ele pontua cada solicitação em relação ao glossário e a cada instrução separadamente. Aprovação ou reprovação com justificativa, acompanhada como série temporal.
| Questão | Ferramentas com escopo de projeto | Engine de localização com escopo organizacional |
|---|---|---|
| Escopo da consistência | Por projeto, por equipe | Por organização |
| Unidade de consistência | Segmento inteiro, indexado por hash | Termo individual, correspondido semanticamente |
| Sobrevive a reescritas na origem | Não | Sim |
| Entre apps e entre equipes | Disciplina; humanos mantêm tudo alinhado | Arquitetural; o engine de localização mantém tudo alinhado |
| Medição de qualidade | Verificações baseadas em regras (tags, números) | Pontuação por solicitação com LLM |
| Flexibilidade de modelo | Dependência de provedor | Cadeia ranqueada |
| Autoridade sobre a saída | Critério do tradutor | O glossário se sobrepõe ao modelo |
O desvio deixa de ser uma condição que você absorve e passa a ser uma condição que você consegue medir. O glossário é acionado em toda solicitação. O avaliador de IA verifica a conformidade em cada solicitação.
O mecanismo tem nome: retrieval augmented localization (RAL). Em tempo de inferência, o engine decompõe a entrada em frases n-gram, gera embeddings e executa uma busca por similaridade de cosseno no índice vetorial do glossário. Os termos correspondentes entram na janela de contexto do modelo antes de o primeiro token ser gerado. Estruturalmente, é idêntico a RAG — aplicado à tradução.
Em uma avaliação controlada com vários provedores de LLM e vários idiomas europeus, RAL reduziu os erros de terminologia em 17–45%. Mais de 42.000 julgamentos de qualidade em pares. p corrigido por Holm-Bonferroni < 0,001 em todos os provedores. As pontuações holísticas de qualidade não detectaram a diferença.
Arquitetura nº 2: engenharia de localização forward-deployed#
A segunda parede é a migração. Você tem uma stack que funciona. Ela cria esse imposto, mas funciona. O custo de substituí-la — tempo de engenharia, retrabalho de integrações, reonboarding de tradutores, migração de dados históricos — excede, de forma consistente, o custo de continuar pagando esse imposto.
É esse cálculo que explica por que o imposto continua sendo pago. Depois de ver o mesmo gargalo de migração impedir a mudança de empresas sérias repetidas vezes, decidimos absorver a migração nós mesmos.
Quando a Lingo.dev faz o onboarding de uma empresa, nossos engenheiros executam a migração. Não como um contrato de serviços profissionais em cima da licença. Como o caminho padrão de onboarding.
Um engenheiro de localização forward-deployed analisa seu glossário, seus documentos de voz da marca, sua configuração de conectores, seus contratos com tradutores. Ele importa sua memória de tradução de TMX e seu glossário de qualquer formato legado em que ele esteja. Nada é rederivado. Ele constrói o engine de localização na Lingo.dev com sua terminologia pré-carregada. Ele o liga ao seu CI. Ele coloca sua lista de tradutores no pipeline assíncrono para que as pessoas em quem você confia continuem no loop.
É no cenário multi-equipes que a arquitetura se paga. Na versão legada, alinhar a terminologia entre equipes significa N migrações sincronizadas — cada equipe rederivando chaves e TM dentro do próprio projeto. Aqui, o engine de localização é construído uma vez. Cada equipe conecta seu app a ele no próprio ritmo. A consistência entre apps aparece já no primeiro idioma que chega ao engine, não depois que todas as equipes concluem suas próprias migrações.
Nossos engenheiros ficam com você até o próximo deploy em produção — e o seguinte também — até que sua equipe interna assuma o sistema.
É assim que fazemos o onboarding de clientes enterprise.
Quando uma org multi-equipes já está entregando toda semana, tradução não pode virar um ticket de compras entre comprador e fornecedor. Ela precisa rodar junto com o seu próximo deploy em produção, não depois dele. Engenharia forward-deployed é como Palantir, Scale AI, Ramp e outros fornecedores de infraestrutura fazem onboarding de clientes enterprise há mais de uma década.
Agora, queremos que a localização finalmente acompanhe.
Auditoria
Um engenheiro da Lingo.dev analisa seus repositórios de origem, sua TM existente (incluindo exportações TMX), seu glossário, seus conectores e seus contratos com tradutores — em todas as equipes responsáveis por uma superfície. Ele produz um plano de migração com ordem e cronograma. O plano é seu.
Engine construído para igualar sua qualidade atual
Configuramos o engine de localização com seu glossário importado, sua voz da marca por idioma e seu pipeline de tradutores. Antes de qualquer tráfego de produção, executamos uma comparação lado a lado — a saída da sua ferramenta atual versus a do engine, mesmas strings, mesma semana. Você decide se a qualidade se sustenta.
Conectado ao CI de cada equipe
Sem rip-and-replace. O engine de localização roda como uma etapa no pipeline existente de cada equipe. Fluxos de merge, fluxos de revisão, revisores — tudo continua igual. O engine substitui a etapa antiga.
Cutover no seu ritmo
Primeiro uma equipe, um par de idiomas. Depois três. Depois o restante. Você escolhe a ordem. Rodamos a comparação em cada etapa. O rollback é um commit.
Transferência para sua equipe
Nosso engenheiro transfere o sistema para sua equipe de plataforma — documentação, runbooks e uma rotação de on-call que cobrimos até que ela assuma.
Evidências#
Pesquisa. O estudo RAL: mais de 42.000 julgamentos de qualidade em pares, em vários provedores de LLM e vários idiomas europeus. p corrigido por Holm-Bonferroni < 0,001 em todos os provedores. A redução nos erros de terminologia variou de 17% a 45%.
Configuração acima da escolha do modelo. Descobrimos que, entre Mistral, Gemini, Claude e GPT, qualquer modelo + um bom glossário, voz da marca e configuração de contexto produz, de forma consistente, traduções prontas para publicação e com qualidade de referência, por uma fração do custo. Não porque melhoramos o modelo. Em cada solicitação, o engine de localização recupera por busca de similaridade os termos correspondentes do glossário, a voz da marca e as instruções por idioma, e os injeta na janela de contexto do modelo antes de o primeiro token ser gerado.
Escala de produção. Mais de 200 milhões de palavras traduzidas na plataforma.
Clientes nomeados. Mistral, Solana, SoSafe, Cal.com.
Escopo#
A Lingo.dev atende equipes de localização de todos os tipos — empresas com um único produto, projetos open source, times focados só em mobile e plataformas enterprise. A arquitetura descrita aqui foi ajustada para empresas com várias equipes lançando vários apps em mais de 20 idiomas.
O que vem a seguir#
O primeiro passo é um piloto de duas semanas. Uma equipe, um par de idiomas.
Um engenheiro de localização dedicado trabalha lado a lado com o responsável pela localização e com a liderança de engenharia. Estudamos seu workflow. Configuramos um sistema de medição para que você possa acompanhar a qualidade das traduções em idiomas que sua equipe não domina — avaliadores de IA rodando em modelos independentes, avaliando cada tradução com base no seu glossário e nas suas regras. A pontuação é adaptada do MQM, o framework padrão de avaliação da qualidade de tradução.
Construímos o engine de localização com base no seu glossário e nos seus documentos de voz da marca. Colocamos ele para rodar no seu conteúdo-fonte, lado a lado com a sua ferramenta atual. Você vê a diferença e decide.
A partir daí, planejamos a migração das equipes e dos idiomas restantes no seu ritmo, não no nosso.
Fale hoje mesmo com nossos especialistas em engenharia de localização.
