Onde o Lovable lê as regras de i18n? Knowledge, skills e AGENTS.md

O Lovable lê as regras de i18n em três lugares: o knowledge do workspace e do projeto, que estão sempre no contexto; as skills, que só são carregadas quando um prompt bate com a descrição delas; e os arquivos de instrução do repositório conectado, em que um AGENTS.md na raiz é lido não importa há quanto tempo a conversa esteja rolando. Se você colocar as regras no lugar errado, o app que você traduziu semana passada entrega a próxima funcionalidade em inglês. A globalize.now é uma infraestrutura de localização com IA, então vemos o resultado desse erro em muitos repositórios do Lovable; a solução está, em boa parte, em saber qual superfície é lida em cada momento.

Por que um app Lovable traduzido volta a ficar em inglês?

Porque a instrução que o deixou multilíngue não estava diante do agente quando ele escreveu o componente seguinte. O Lovable resolve o prompt que está na tela. Se esse prompt diz "adicione uma seção de depoimentos" e nada no contexto diz "toda string visível ao usuário passa por <Trans>", o título entra como literal, exatamente como entraria em um projeto novo.

Esse não é o mesmo problema dos catálogos que ficam para trás em relação ao código, que é a falha de sincronização tratada em por que as traduções do seu app Lovable quebram a cada lançamento. A sincronização move strings já envolvidas em macros para os arquivos de locale. Ela não consegue mover uma string que nunca foi envolvida. A questão anterior a isso é o que o Lovable estava lendo no momento em que escreveu o código, e a documentação dele é incomumente específica sobre isso.

O que o Lovable realmente lê antes de editar?

Segundo a documentação de knowledge, o project knowledge, o workspace knowledge e os arquivos de instrução do repositório Git, como AGENTS.md ou CLAUDE.md, orientam o agente junto com o código do projeto. As skills são separadas e carregadas sob demanda.

Eles diferem em três aspectos que importam para i18n.

Quando são lidos. O knowledge é incluído em toda mensagem. Uma skill só é incluída quando o pedido bate com a descrição dela. Um AGENTS.md na raiz é, nas palavras do Lovable, sempre lido, independentemente do tamanho da sessão.

Quão duráveis são em um chat longo. A documentação do Lovable traz um aviso explícito: em conversas muito longas e com muito contexto, as instruções do knowledge podem nem sempre ser seguidas de forma consistente. A mesma página afirma o oposto sobre o AGENTS.md na raiz. Essa assimetria é a razão de ser deste post.

Quem pode editá-los. O workspace knowledge é restrito a owners e admins. O project knowledge pode ser editado por qualquer pessoa com permissão de edição no projeto. O arquivo do repositório é editado por quem puder fazer push, o que inclui o próprio agente do Lovable.

Cada nível de knowledge comporta até 10.000 caracteres. É bastante para um ponteiro e muito pouco para o conjunto completo de regras, principalmente se você também quiser colocar ali notas de arquitetura, schema do banco de dados e tom de voz da marca.

Então onde as regras de i18n devem ficar?

No repositório, com um ponteiro curto no knowledge. O raciocínio decorre do que vimos acima.

O AGENTS.md na raiz do repositório carrega as regras completas. Ele é lido em toda mensagem, independentemente do tamanho da sessão; vive no Git, então sobrevive a um novo chat, a um novo colaborador e à troca para outro agente; e não tem limite de caracteres competindo com o restante do contexto do seu projeto. Quando a skill lovable-i18n executa o setup, a terceira fase escreve exatamente esse arquivo: um bloco de regras do Lingui entre os marcadores <!-- lovable-i18n:rules:start --> e <!-- lovable-i18n:rules:end -->, criado se o arquivo não existir, adicionado ao final se ele já existir e substituído entre os marcadores em uma nova execução, para que nada seja duplicado.

O project knowledge carrega um ponteiro de duas linhas. Algo como:

Localization
- This app is localized with Lingui. Every user-visible string is wrapped
  (<Trans>, t``, msg``) and new strings are appended to src/locales/*/messages.po.
- The full rules are in AGENTS.md at the repo root. Follow them on every edit.

O ponteiro existe para o caso sobre o qual a documentação alerta. Se uma conversa longa diluiu o bloco de knowledge, o agente ainda tem o arquivo do repositório; se, por algum motivo, o arquivo do repositório não estiver no contexto, o ponteiro nomeia a restrição. Duas superfícies, uma regra.

Workspace knowledge só se todos os projetos usarem a mesma biblioteca. O workspace knowledge vale para todos os projetos do workspace e existe exatamente um. Se metade dos seus projetos usa Lingui e a outra metade usa outra coisa, uma regra do Lingui no nível do workspace está errada para metade deles, e o Lovable é orientado a priorizar o project knowledge em caso de conflito de qualquer forma. Reserve o workspace knowledge para regras que valem em qualquer lugar: botões em sentence case, sem console.log, comentários de código em inglês.

A skill não é o lugar das regras. Isso surpreende quem acabou de importá-la. Uma skill é carregada quando o prompt bate com a descrição dela, então lovable-i18n está no contexto quando você pede o setup de i18n e ausente quando você pede uma página de checkout. Isso é proposital; uma skill carregada em toda mensagem seria só knowledge. O trabalho da skill é escrever as regras duráveis no repositório uma vez e depois sair do caminho.

O que dizem as regras do AGENTS.md?

Elas respondem às perguntas em que um agente erra quando só recebe a ordem de "usar i18n". O bloco que a skill escreve tem seis partes.

Qual macro usar. Uma lista de decisão: texto que muda conforme um número usa <Plural> ou um plural ICU; texto em JSX usa <Trans>; valores de atributos e strings em event handlers, como toasts, usam o t retornado por useLingui(); constantes no escopo do módulo usam msg e são resolvidas dentro do componente. A regra também diz de qual caminho de import cada uma vem, porque importar o t errado vincula uma instância global que o app nunca carrega.

Interpolação. Só uma variável simples dá nome ao próprio slot na mensagem extraída. Qualquer outra expressão é extraída como {0}, algo com que um tradutor não consegue trabalhar, então a regra exige ph() para nomeá-la.

Plurais. other é sempre obrigatório, as categorias seguem o CLDR e um ternário entre duas strings é proibido, porque embute as regras de plural do inglês no componente. Se quiser entender melhor, o que é o ICU MessageFormat explica a sintaxe para a qual as formas plurais são compiladas.

Números e datas. i18n.number() e i18n.date(), nunca toFixed() nem um símbolo de moeda concatenado a um valor. O próprio exemplo de workspace knowledge do Lovable inclui uma seção de localização que define um formato de data e a formatação numérica europeia, o que é um bom instinto, mas é uma regra de formatação, não de envolvimento em macros. Um app pode segui-la à risca e mesmo assim entregar todos os títulos em inglês.

Comentários para tradutores. Strings curtas com várias leituras possíveis, rótulos de ação soltos e termos de domínio recebem um comment= descrevendo onde a string aparece. context= fica reservado para quando o mesmo texto precisa de traduções diferentes em lugares diferentes.

Manutenção do catálogo. Toda string nova é envolvida em macro e adicionada a cada src/locales/*/messages.po com um msgstr vazio, de modo que o Lingui use o texto de origem como fallback até a tradução chegar. O agente nunca roda lingui extract, porque não há terminal no Lovable; um GitHub Action faz isso depois da sincronização. E ele nunca edita as linhas de comentário #. e #: das entradas existentes, porque a extração as regenera.

Essa última seção é o que torna as regras específicas para o Lovable. Um arquivo de regras do Cursor ou do Claude Code pode terminar com "rode o linter". Um arquivo de regras do Lovable não pode, então precisa dizer o que fazer manualmente e o que deixar para o CI.

O que garante a regra quando o Lovable não consegue rodar nada?

O workflow do GitHub, e somente ele. O Lovable não tem terminal, então não existe etapa de lint entre o agente escrever um literal e a alteração ser sincronizada com o repositório. Essa é a diferença estrutural em relação aos agentes de IDE, em que uma regra de lint no CI é o que faz o build falhar diante de uma string hardcoded.

Se você aceitar durante o setup, a skill adiciona um workflow do GitHub Actions que roda nos pushes para a branch padrão, que é onde cai a sincronização do Lovable, extrai as strings envolvidas em macros para os catálogos e faz o commit de uma sincronização de catálogo. Se o app do GitHub não tiver a permissão workflows, a skill pede que você adicione o arquivo manualmente no GitHub. Isso fecha o ciclo para tudo o que o agente envolveu em macros. Não faz nada por uma string que o agente não envolveu, porque a extração só enxerga macros.

Então o retrato honesto é este: as regras no AGENTS.md reduzem a frequência de literais sem macro, o ponteiro no knowledge dá suporte a elas em chats longos e o diff no GitHub é onde você pega o resto. Se quiser que uma máquina pegue o resto, adicione a regra no-literal-string do eslint-plugin-i18next como uma etapa do mesmo workflow. Ela roda no repositório, que é o único lugar onde um projeto Lovable consegue rodar qualquer coisa.

O que acontece com as strings que são envolvidas em macros?

Elas precisam ser traduzidas, e essa é a parte que vale automatizar em vez de ficar refazendo prompts. A conversão é feita uma única vez, dentro do app: você conecta o repositório e a globalize.now converte o código uma vez, entregando o catálogo em um pull request para você revisar. Depois disso, jobs de push traduzem as novas unidades de catálogo conforme elas chegam, então um <Trans> que o Lovable escreveu na terça já tem as traduções em um pull request na quarta. Sem etapa em dashboard, sem exportação, sem fila de aprovação; o argumento completo a favor desse formato está em localizar um app Lovable sem dashboard, e o passo a passo exato, incluindo a conexão com o GitHub e o conector da globalize, está na página de integração com o Lovable.

Uma nota histórica, porque ela explica por que esse problema parece novo para alguns builders do Lovable. O Lovalingo traduzia apps Lovable em runtime, no navegador, então um componente novo gerado em inglês simplesmente era retraduzido no carregamento e a recorrência nunca aparecia. Ele foi encerrado em 31 de agosto de 2026, e os apps que migraram para catálogos versionados pelo guia de migração estão encontrando essa questão anterior pela primeira vez. O modelo de catálogo é a escolha certa, já que o markup traduzido é seu e indexável, mas ele exige que o agente escreva código traduzível, e isso significa dizer a ele onde estão as regras.

Coloque as regras onde o Lovable as lê

Rode a skill uma vez para que o AGENTS.md carregue o bloco completo, cole o ponteiro de duas linhas no project knowledge e deixe o workflow do GitHub fazer a extração que o editor não consegue. Se você está construindo no Lovable e quer que a tradução de tudo o que chega ao catálogo seja resolvida em vez de mantida na mão, a página para vibe coders traz a visão geral e os preços ficam em uma página própria.