Où Lovable lit-il les règles i18n ? Knowledge, compétences et AGENTS.md

Lovable lit les règles i18n à trois endroits : le knowledge du workspace et du projet, toujours dans le contexte ; les compétences, qui ne se chargent que lorsqu’un prompt correspond à leur description ; et les fichiers d’instructions du dépôt connecté, où un AGENTS.md à la racine est lu quelle que soit la durée de la conversation. Mettez les règles au mauvais endroit et l’app que vous avez traduite la semaine dernière livrera sa prochaine fonctionnalité en anglais. globalize.now est une infrastructure de localisation propulsée par l’IA : nous voyons donc le résultat de cette erreur dans de nombreux repos Lovable. Le correctif consiste surtout à savoir quelle surface est lue, et quand.

Pourquoi une app Lovable traduite retombe-t-elle en anglais ?

Parce que l’instruction qui l’avait rendue multilingue n’était pas sous les yeux de l’agent quand il a écrit le composant suivant. Lovable répond au prompt affiché à l’écran. Si ce prompt dit « ajoute une section témoignages » et que rien dans le contexte ne dit « toute chaîne visible par l’utilisateur passe par <Trans> », le titre atterrit en littéral, exactement comme dans un projet vierge.

Ce n’est pas le même problème que celui des catalogues qui prennent du retard sur le code, c’est-à-dire l’échec de synchronisation traité dans pourquoi les traductions de votre app Lovable cassent à chaque livraison. La synchronisation déplace les chaînes encapsulées vers les fichiers de locale. Elle ne peut pas déplacer une chaîne qui n’a jamais été encapsulée. La question en amont est de savoir ce que Lovable lisait au moment où il a écrit le code, et la documentation de Lovable est très précise sur ce point.

Que lit réellement Lovable avant de modifier le code ?

D’après sa documentation sur le knowledge, le project knowledge, le workspace knowledge et les fichiers d’instructions du dépôt Git comme AGENTS.md ou CLAUDE.md guident tous l’agent, en plus du code du projet. Les compétences sont à part et se chargent à la demande.

Ils diffèrent sur trois points qui comptent pour l’i18n.

Quand ils sont lus. Le knowledge est inclus à chaque message. Une compétence n’est incluse que si la requête correspond à sa description. Un AGENTS.md à la racine est, selon les mots de Lovable, toujours lu quelle que soit la durée de la session.

Leur durabilité dans un long chat. La documentation de Lovable contient une réserve explicite : dans de très longues conversations avec beaucoup de contexte, les instructions du knowledge ne sont pas toujours suivies de façon cohérente. La même page affirme l’inverse pour le AGENTS.md à la racine. Cette asymétrie est la raison d’être de cet article.

Qui peut les modifier. Le workspace knowledge est réservé aux propriétaires et aux admins. Le project knowledge peut être modifié par toute personne ayant des droits d’édition sur le projet. Le fichier du dépôt est modifié par quiconque peut faire un push, y compris l’agent Lovable lui-même.

Chaque niveau de knowledge accepte jusqu’à 10 000 caractères. C’est largement assez pour un pointeur, et bien trop peu pour l’ensemble des règles dès lors que vous voulez aussi y mettre des notes d’architecture, le schéma de base de données et la voix de marque.

Où placer les règles i18n, alors ?

Dans le dépôt, avec un court pointeur dans le knowledge. Le raisonnement découle du tableau ci-dessus.

Le AGENTS.md à la racine du repo porte l’ensemble des règles. Il est lu à chaque message quelle que soit la durée de la session, il vit dans Git : il survit donc à un nouveau chat, à un nouveau collaborateur et à un changement d’agent, et aucune limite de caractères ne le met en concurrence avec le reste du contexte de votre projet. Quand la compétence lovable-i18n exécute son installation, sa troisième phase écrit exactement ce fichier : un bloc de règles Lingui entre des marqueurs <!-- lovable-i18n:rules:start --> et <!-- lovable-i18n:rules:end -->, créé si le fichier est absent, ajouté s’il existe, et remplacé entre les marqueurs à chaque relance pour que rien ne soit dupliqué.

Le project knowledge porte un pointeur de deux lignes. Quelque chose comme :

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.

Le pointeur est là pour le cas contre lequel la documentation met en garde. Si une longue conversation a dilué le bloc de knowledge, l’agent dispose toujours du fichier du repo ; si, pour une raison quelconque, le fichier du repo n’est pas dans le contexte, le pointeur nomme la contrainte. Deux surfaces, une seule règle.

Le workspace knowledge uniquement si tous les projets utilisent la même bibliothèque. Le workspace knowledge s’applique à tous les projets du workspace et il n’en existe qu’un seul. Si la moitié de vos projets utilisent Lingui et l’autre moitié autre chose, une règle Lingui au niveau du workspace est fausse pour la moitié d’entre eux, et Lovable est de toute façon encouragé à donner la priorité au project knowledge en cas de conflit. Réservez le workspace knowledge aux règles vraies partout : boutons en sentence case, pas de console.log, commentaires de code en anglais.

La compétence n’est pas le lieu où ranger les règles. Cela surprend ceux qui viennent de l’importer. Une compétence se charge quand le prompt correspond à sa description : lovable-i18n est donc dans le contexte quand vous demandez une configuration i18n, et absente quand vous demandez une page de paiement. C’est voulu ; une compétence chargée à chaque message ne serait que du knowledge. Le rôle de la compétence est d’écrire une fois les règles durables dans le repo, puis de s’effacer.

Que disent les règles du fichier AGENTS.md ?

Elles répondent aux questions sur lesquelles un agent se trompe quand on lui dit seulement d’« utiliser l’i18n ». Le bloc que la compétence écrit comporte six parties.

Quelle macro. Une liste de décision : le texte qui varie selon un nombre utilise <Plural> ou un pluriel ICU ; le texte JSX utilise <Trans> ; les valeurs d’attributs et les chaînes de gestionnaires d’événements, comme les toasts, utilisent le t retourné par useLingui() ; les constantes au niveau du module utilisent msg et sont résolues dans le composant. La règle précise aussi le chemin d’import de chacune, car un mauvais import de t lie une instance globale que l’app ne charge jamais.

Interpolation. Seule une variable nue nomme son propre emplacement dans le message extrait. Toute autre expression est extraite en {0}, inexploitable pour un traducteur : la règle exige donc ph() pour la nommer.

Pluriels. other est toujours requis, les catégories sont celles du CLDR, et un ternaire entre deux chaînes est interdit car il fige les règles de pluriel de l’anglais dans le composant. Pour le contexte, ce qu’est ICU MessageFormat couvre la syntaxe vers laquelle les formes plurielles sont compilées.

Nombres et dates. i18n.number() et i18n.date(), jamais toFixed() ni un symbole monétaire concaténé à une valeur. L’exemple de workspace knowledge de Lovable inclut lui-même une section de localisation qui fixe un format de date et un formatage des nombres à l’européenne : le réflexe est bon, mais c’est une règle de formatage, pas une règle d’encapsulation. Une app peut la suivre à la lettre et livrer pourtant tous ses titres en anglais.

Commentaires pour les traducteurs. Les chaînes courtes à plusieurs lectures possibles, les libellés d’action isolés et les termes métier reçoivent un comment= décrivant l’endroit où la chaîne apparaît. context= est réservé au cas où un même texte appelle des traductions différentes selon l’endroit.

Entretien du catalogue. Chaque nouvelle chaîne est encapsulée puis ajoutée à chaque src/locales/*/messages.po avec un msgstr vide, de sorte que Lingui retombe sur le texte source jusqu’à l’arrivée d’une traduction. L’agent n’exécute jamais lingui extract, faute de terminal dans Lovable ; c’est une GitHub Action qui s’en charge après la synchronisation. Et il ne modifie jamais les lignes de commentaire #. et #: des entrées existantes, car l’extraction les régénère.

Cette dernière section est ce qui rend les règles spécifiques à Lovable. Un fichier de règles pour Cursor ou Claude Code peut se terminer par « lance le linter ». Un fichier de règles pour Lovable ne le peut pas : il doit donc dire quoi faire à la main, et quoi laisser à la CI.

Qu’est-ce qui fait respecter la règle quand Lovable ne peut rien exécuter ?

Le workflow GitHub, et lui seul. Lovable n’a pas de terminal : aucune étape de lint ne s’intercale entre l’agent qui écrit un littéral et la synchronisation du changement vers votre dépôt. C’est la différence structurelle avec les agents d’IDE, où une règle de lint en CI fait échouer le build sur une chaîne codée en dur.

Si vous l’activez pendant l’installation, la compétence ajoute un workflow GitHub Actions qui s’exécute sur les push vers la branche par défaut (là où atterrit la synchronisation de Lovable), extrait les chaînes encapsulées dans les catalogues et recommit une synchronisation du catalogue. Si l’app GitHub n’a pas la permission workflows, la compétence vous demande d’ajouter le fichier à la main dans GitHub. Cela ferme la boucle pour tout ce que l’agent a encapsulé. Cela ne sert à rien pour une chaîne que l’agent n’a pas encapsulée, car l’extraction ne voit que les macros.

Voici donc le tableau honnête : les règles du AGENTS.md réduisent la fréquence des littéraux non encapsulés, le pointeur dans le knowledge les épaule dans les longs chats, et le diff dans GitHub est l’endroit où vous attrapez le reste. Si vous voulez qu’une machine attrape le reste, ajoutez la règle no-literal-string de eslint-plugin-i18next comme étape du même workflow. Elle s’exécute sur le repo, le seul endroit où un projet Lovable peut exécuter quoi que ce soit.

Que deviennent les chaînes qui, elles, sont bien encapsulées ?

Elles doivent être traduites, et c’est la partie qui mérite d’être automatisée plutôt que reprompée. La conversion se fait une seule fois, dans l’app : connectez le dépôt, et globalize.now convertit le code une fois, en livrant le catalogue sous forme de pull request à relire. Ensuite, des jobs déclenchés par chaque push traduisent les nouvelles unités de catalogue à mesure qu’elles arrivent : un <Trans> que Lovable a écrit mardi a ses traductions dans une pull request dès mercredi. Pas d’étape dans un tableau de bord, pas d’export, pas de file d’approbation ; l’argumentaire détaillé de ce modèle se trouve dans localiser une app Lovable sans tableau de bord, et la marche à suivre exacte, y compris la connexion GitHub et le connecteur globalize, est sur la page d’intégration Lovable.

Une note historique, parce qu’elle explique pourquoi ce problème semble nouveau à certains builders Lovable. Lovalingo traduisait les apps Lovable à l’exécution, dans le navigateur : un composant anglais fraîchement généré était simplement retraduit au chargement, et le problème ne se voyait jamais. Le service a fermé le 31 août 2026, et les apps qui sont passées à des catalogues commités via le guide de migration rencontrent la question en amont pour la première fois. Le modèle du catalogue est le bon compromis, puisque le markup traduit vous appartient et reste indexable, mais il demande à l’agent d’écrire du code traduisible, ce qui implique de lui dire où se trouvent les règles.

Mettez les règles là où Lovable les lit

Lancez la compétence une fois pour que AGENTS.md porte le bloc complet, collez le pointeur de deux lignes dans le project knowledge, et laissez le workflow GitHub faire l’extraction que l’éditeur ne peut pas faire. Si vous construisez dans Lovable et que vous voulez que la traduction de tout ce qui arrive dans le catalogue soit prise en charge plutôt que maintenue, la page vibe coders en donne la vue d’ensemble et la tarification a sa propre page.