Dove legge Lovable le regole i18n? Knowledge, skill e AGENTS.md

Lovable legge le regole i18n da tre posti: la knowledge di workspace e di progetto, sempre nel contesto; le skill, che si caricano solo quando un prompt corrisponde alla loro descrizione; e i file di istruzioni nel repository connesso, dove un AGENTS.md alla root viene letto a prescindere da quanto sia lunga la conversazione. Metti le regole nel posto sbagliato e l'app tradotta la settimana scorsa rilascia la funzionalità successiva in inglese. globalize.now è un'infrastruttura di localizzazione basata su IA, quindi vediamo le conseguenze di questo errore in molti repository Lovable; la soluzione consiste soprattutto nel sapere quale superficie viene letta e quando.

Perché un'app Lovable tradotta torna all'inglese?

Perché l'istruzione che l'aveva resa multilingue non era davanti all'agente quando ha scritto il componente successivo. Lovable risolve il prompt che ha sullo schermo. Se il prompt dice «aggiungi una sezione testimonianze» e nel contesto non c'è scritto «ogni stringa visibile all'utente passa da <Trans>», il titolo finisce come literal, esattamente come in un progetto nuovo.

Non è lo stesso problema dei catalog che restano indietro rispetto al codice, cioè il fallimento di sync trattato in perché le traduzioni della tua app Lovable si rompono a ogni rilascio. Il sync sposta le stringhe incapsulate nei file di traduzione. Non può spostare una stringa che non è mai stata incapsulata. La domanda a monte è cosa stava leggendo Lovable nel momento in cui ha scritto il codice, e la documentazione di Lovable è insolitamente precisa su questo.

Cosa legge davvero Lovable prima di modificare?

Secondo la sua documentazione sulla knowledge, la project knowledge, la workspace knowledge e i file di istruzioni nel repository Git, come AGENTS.md o CLAUDE.md, guidano tutti l'agente, insieme al codice del progetto. Le skill sono separate e si caricano on demand.

Si distinguono per tre aspetti che contano per l'i18n.

Quando vengono lette. La knowledge è inclusa a ogni messaggio. Una skill è inclusa solo quando la richiesta corrisponde alla sua descrizione. Un AGENTS.md alla root, per dirla con le parole di Lovable, viene sempre letto a prescindere dalla lunghezza della sessione.

Quanto reggono in una chat lunga. La documentazione di Lovable contiene un'avvertenza esplicita: nelle conversazioni molto lunghe e con molto contesto, le istruzioni della knowledge potrebbero non essere sempre seguite in modo coerente. La stessa pagina afferma il contrario per l'AGENTS.md alla root. Questa asimmetria è l'unico motivo per cui esiste questo post.

Chi può modificarle. La workspace knowledge è modificabile solo da owner e admin. La project knowledge può essere modificata da chiunque abbia diritti di modifica sul progetto. Il file nel repository viene modificato da chiunque possa fare push, incluso l'agente Lovable stesso.

Ogni livello di knowledge contiene fino a 10.000 caratteri. Bastano e avanzano per un puntatore, ma sono troppo pochi per l'intero set di regole se vuoi metterci anche note di architettura, schema del database e brand voice.

Quindi dove vanno le regole i18n?

Nel repository, con un breve puntatore nella knowledge. Il ragionamento segue da quanto sopra.

AGENTS.md alla root del repo contiene le regole complete. Viene letto a ogni messaggio a prescindere dalla lunghezza della sessione, vive in Git quindi sopravvive a una nuova chat, a un nuovo collaboratore e al passaggio a un altro agente, e non ha un limite di caratteri che competa con il resto del contesto del progetto. Quando la skill lovable-i18n esegue il setup, la sua terza fase scrive esattamente questo file: un blocco di regole Lingui tra i marker <!-- lovable-i18n:rules:start --> e <!-- lovable-i18n:rules:end -->, creato se il file manca, aggiunto in coda se esiste e sostituito tra i marker a ogni riesecuzione, così non si duplica nulla.

La project knowledge contiene un puntatore di due righe. Qualcosa come:

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.

Il puntatore serve per il caso che la documentazione segnala. Se una conversazione lunga ha diluito il blocco di knowledge, l'agente ha comunque il file nel repo; se per qualche motivo il file nel repo non è nel contesto, il puntatore nomina il vincolo. Due superfici, una regola.

La workspace knowledge solo se tutti i progetti usano la stessa libreria. La workspace knowledge si applica a tutti i progetti del workspace e ce n'è una sola. Se metà dei tuoi progetti usa Lingui e metà qualcos'altro, una regola Lingui a livello di workspace è sbagliata per metà di essi, e comunque Lovable è incoraggiato a dare priorità alla project knowledge in caso di conflitto. Tieni la workspace knowledge per le regole valide ovunque: button in sentence case, niente console.log, commenti del codice in inglese.

La skill non è la casa delle regole. Questo sorprende chi l'ha appena importata. Una skill si carica quando il prompt corrisponde alla sua descrizione, quindi lovable-i18n è nel contesto quando chiedi il setup i18n e assente quando chiedi una pagina di checkout. È voluto; una skill caricata a ogni messaggio sarebbe semplicemente knowledge. Il compito della skill è scrivere una volta le regole durevoli nel repo e poi togliersi di mezzo.

Cosa dicono le regole in AGENTS.md?

Rispondono alle domande su cui un agente sbaglia quando gli viene detto solo di «usare l'i18n». Il blocco che la skill scrive ha sei parti.

Quale macro. Una lista decisionale: il testo che cambia con un numero usa <Plural> o un plurale ICU; il testo JSX usa <Trans>; i valori degli attributi e le stringhe negli event handler, come i toast, usano t restituito da useLingui(); le costanti a livello di modulo usano msg e vengono risolte dentro il componente. La regola indica anche da quale path di import arriva ciascuna, perché l'import sbagliato di t lega un'istanza globale che l'app non carica mai.

Interpolazione. Solo una variabile semplice dà il nome al proprio slot nel messaggio estratto. Qualsiasi altra espressione viene estratta come {0}, con cui un traduttore non può lavorare, quindi la regola richiede ph() per nominarla.

Plurali. other è sempre obbligatorio, le categorie sono CLDR e un ternario tra due stringhe è vietato perché incorpora le regole di plurale dell'inglese nel componente. Se vuoi il contesto, cos'è ICU MessageFormat copre la sintassi in cui compilano le forme plurali.

Numeri e date. i18n.number() e i18n.date(), mai toFixed() o un simbolo di valuta concatenato a un valore. L'esempio di workspace knowledge di Lovable include una sezione di localizzazione che imposta un formato data e la formattazione numerica europea: è un buon istinto, ma è una regola di formattazione, non di wrapping. Un'app può seguirla alla perfezione e rilasciare comunque ogni titolo in inglese.

Commenti per i traduttori. Le stringhe brevi con più letture possibili, le label di azione nude e i termini di dominio ricevono un comment= che descrive dove compare la stringa. context= è riservato al caso in cui lo stesso testo richiede traduzioni diverse in posti diversi.

Manutenzione dei catalog. Ogni nuova stringa viene incapsulata e aggiunta a ciascun src/locales/*/messages.po con un msgstr vuoto, così Lingui ripiega sul testo sorgente finché non arriva una traduzione. L'agente non esegue mai lingui extract, perché in Lovable non c'è un terminale; lo fa una GitHub Action dopo il sync. E non modifica mai le righe di commento #. e #: sulle entry esistenti, perché l'estrazione le rigenera.

Quest'ultima sezione è ciò che rende le regole specifiche per Lovable. Un file di regole per Cursor o Claude Code può chiudersi con «esegui il linter». Un file di regole per Lovable no, quindi deve dire cosa fare a mano e cosa lasciare alla CI.

Cosa fa rispettare la regola quando Lovable non può eseguire nulla?

Il workflow GitHub, e solo il workflow GitHub. Lovable non ha un terminale, quindi non esiste uno step di lint tra l'agente che scrive un literal e la modifica che si sincronizza sul repository. È la differenza strutturale rispetto agli agent da IDE, dove una regola di lint in CI è ciò che fa fallire la build davanti a una stringa hardcoded.

Se accetti durante il setup, la skill aggiunge un workflow GitHub Actions che gira sui push al branch di default, dove arriva il sync di Lovable, estrae le stringhe incapsulate nei catalog e fa il commit di un sync del catalog. Se l'app GitHub non ha il permesso workflows, la skill ti chiede di aggiungere il file a mano su GitHub. Questo chiude il cerchio per tutto ciò che l'agente ha incapsulato. Non fa nulla per una stringa che l'agente non ha incapsulato, perché l'estrazione vede solo le macro.

Quindi il quadro onesto è questo: le regole in AGENTS.md riducono la frequenza dei literal non incapsulati, il puntatore nella knowledge le rinforza nelle chat lunghe e il diff su GitHub è dove intercetti il resto. Se vuoi che sia una macchina a intercettare il resto, aggiungi la regola no-literal-string di eslint-plugin-i18next come step nello stesso workflow. Gira sul repository, l'unico posto in cui un progetto Lovable può eseguire qualcosa.

Cosa succede alle stringhe che vengono incapsulate?

Vanno tradotte, ed è la parte che vale la pena automatizzare invece di rifare il prompt. La conversione avviene una sola volta, nell'app: connetti il repository e globalize.now converte la codebase una volta, consegnando il catalog come pull request da rivedere. Poi i job di push traducono le nuove unità del catalog man mano che arrivano, quindi un <Trans> scritto da Lovable il martedì ha le sue traduzioni in una pull request entro il mercoledì. Nessuno step da dashboard, nessun export, nessuna coda di approvazione; l'argomento più esteso a favore di questo approccio è in localizzare un'app Lovable senza dashboard, e il percorso di setup esatto, inclusa la connessione GitHub e il connector globalize, è nella pagina dell'integrazione Lovable.

Una nota storica, perché spiega come mai questo problema sembra nuovo ad alcuni builder Lovable. Lovalingo traduceva le app Lovable a runtime nel browser, quindi un componente inglese appena generato veniva semplicemente ritradotto al caricamento e il problema non emergeva mai. Ha chiuso il 31 agosto 2026, e le app passate ai catalog committati tramite la guida alla migrazione incontrano per la prima volta la questione a monte. Il modello a catalog è il compromesso giusto, perché il markup tradotto è tuo e indicizzabile, ma chiede all'agente di scrivere codice traducibile, e questo significa dirgli dove sono le regole.

Metti le regole dove Lovable le legge

Esegui la skill una volta così che AGENTS.md contenga il blocco completo, incolla il puntatore di due righe nella project knowledge e lascia che il workflow GitHub faccia l'estrazione che l'editor non può fare. Se sviluppi in Lovable e vuoi che la traduzione di tutto ciò che arriva nel catalog sia gestita e non mantenuta a mano, la pagina per i vibe coder è la panoramica e i prezzi hanno una pagina a parte.