Woher liest Lovable i18n-Regeln? Knowledge, Skills und AGENTS.md

Lovable liest i18n-Regeln aus drei Quellen: Workspace- und Projekt-Knowledge, die immer im Kontext sind; Skills, die nur laden, wenn ein Prompt zu ihrer Beschreibung passt; und Instruction-Dateien im verbundenen Repository, wo eine AGENTS.md im Root unabhängig davon gelesen wird, wie lange die Konversation schon läuft. Landen die Regeln an der falschen Stelle, liefert die App, die du letzte Woche übersetzt hast, ihr nächstes Feature auf Englisch aus. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur – wir sehen die Folgen dieses Fehlers in vielen Lovable-Repos. Die Lösung besteht meist darin, zu wissen, welche Ebene wann gelesen wird.

Warum rutscht eine übersetzte Lovable-App wieder ins Englische zurück?

Weil die Anweisung, die sie mehrsprachig gemacht hat, dem Agent beim Schreiben der nächsten Komponente nicht vorlag. Lovable löst den Prompt, der gerade auf dem Bildschirm steht. Lautet der Prompt „add a testimonials section“ und steht im Kontext nichts von „every user-visible string goes through <Trans>“, landet die Überschrift als Literal im Code – genau wie in einem frischen Projekt.

Das ist nicht dasselbe Problem wie Kataloge, die dem Code hinterherhinken – diesen Sync-Fehler behandelt warum die Übersetzungen deiner Lovable-App bei jedem Release brechen. Der Sync verschiebt gewrappte Strings in Locale-Dateien. Einen String, der nie gewrappt wurde, kann er nicht verschieben. Die Frage davor lautet: Was hat Lovable gelesen, als es den Code geschrieben hat? Und dazu ist Lovables Dokumentation ungewöhnlich konkret.

Was liest Lovable tatsächlich, bevor es etwas ändert?

Laut Knowledge-Doku steuern Projekt-Knowledge, Workspace-Knowledge und Instruction-Dateien im Git-Repository wie AGENTS.md oder CLAUDE.md den Agent – zusätzlich zum Projektcode. Skills sind davon getrennt und laden auf Abruf.

Sie unterscheiden sich in drei Punkten, die für i18n zählen.

Wann sie gelesen werden. Knowledge wird bei jeder Nachricht mitgeschickt. Ein Skill kommt nur dazu, wenn die Anfrage zu seiner Beschreibung passt. Eine AGENTS.md im Root wird, in Lovables Worten, immer gelesen – unabhängig von der Länge der Session.

Wie robust sie in einem langen Chat sind. Lovables Doku enthält den ausdrücklichen Hinweis, dass Knowledge-Anweisungen in sehr langen Konversationen mit viel Kontext nicht immer konsistent befolgt werden. Für die AGENTS.md im Root behauptet dieselbe Seite das Gegenteil. Genau diese Asymmetrie ist der Grund für diesen Beitrag.

Wer sie bearbeiten kann. Workspace-Knowledge dürfen nur Owner und Admins bearbeiten. Projekt-Knowledge kann jeder bearbeiten, der Schreibrechte im Projekt hat. Die Repo-Datei bearbeitet, wer pushen darf – inklusive des Lovable-Agents selbst.

Jede Knowledge-Ebene fasst bis zu 10.000 Zeichen. Für einen Verweis ist das reichlich, für das vollständige Regelwerk aber viel zu knapp, sobald du zusätzlich Architekturnotizen, Datenbankschema und Brand Voice unterbringen willst.

Wohin gehören die i18n-Regeln also?

Ins Repository, mit einem kurzen Verweis im Knowledge. Die Begründung ergibt sich aus dem Vergleich oben.

Die AGENTS.md im Repo-Root enthält das vollständige Regelwerk. Sie wird bei jeder Nachricht gelesen, egal wie lang die Session ist. Sie liegt in Git und überlebt damit einen neuen Chat, neue Mitwirkende und den Wechsel zu einem anderen Agent. Und sie hat kein Zeichenlimit, das mit dem übrigen Projektkontext konkurriert. Wenn der lovable-i18n-Skill sein Setup durchläuft, schreibt seine dritte Phase genau diese Datei: einen Lingui-Regelblock zwischen den Markern <!-- lovable-i18n:rules:start --> und <!-- lovable-i18n:rules:end --> – angelegt, falls die Datei fehlt, angehängt, falls sie existiert, und bei einem erneuten Lauf zwischen den Markern ersetzt, sodass nichts doppelt landet.

Das Projekt-Knowledge enthält einen Zweizeiler als Verweis. Etwa so:

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.

Der Verweis deckt genau den Fall ab, vor dem die Doku warnt. Hat ein langer Chat den Knowledge-Block verwässert, hat der Agent immer noch die Repo-Datei. Und sollte die Repo-Datei aus irgendeinem Grund nicht im Kontext sein, benennt der Verweis die Vorgabe. Zwei Ebenen, eine Regel.

Workspace-Knowledge nur, wenn jedes Projekt dieselbe Bibliothek nutzt. Workspace-Knowledge gilt für alle Projekte im Workspace, und es gibt davon genau eines pro Workspace. Ist die Hälfte deiner Projekte auf Lingui und die andere Hälfte auf etwas anderem, ist eine Lingui-Regel auf Workspace-Ebene für die Hälfte falsch – und bei einem Konflikt soll Lovable ohnehin das Projekt-Knowledge bevorzugen. Nutze das Workspace-Knowledge für Regeln, die überall stimmen: Buttons in Sentence Case, kein console.log, englische Code-Kommentare.

Der Skill ist nicht der Ort für die Regeln. Das überrascht Leute, die ihn gerade erst importiert haben. Ein Skill lädt, wenn der Prompt zu seiner Beschreibung passt. lovable-i18n ist also im Kontext, wenn du nach dem i18n-Setup fragst, und fehlt, wenn du eine Checkout-Seite anforderst. Das ist Absicht: Ein Skill, der bei jeder Nachricht lädt, wäre einfach Knowledge. Die Aufgabe des Skills ist, die dauerhaften Regeln einmal ins Repo zu schreiben und sich dann rauszuhalten.

Was steht in den Regeln der AGENTS.md?

Sie beantworten die Fragen, an denen ein Agent scheitert, wenn man ihm nur sagt, er solle „i18n verwenden“. Der Block, den der Skill schreibt, besteht aus sechs Teilen.

Welches Macro. Eine Entscheidungsliste: Text, der sich mit einer Zahl ändert, nutzt <Plural> oder einen ICU-Plural; JSX-Text nutzt <Trans>; Attributwerte und Strings in Event-Handlern wie Toasts nutzen das t, das useLingui() zurückgibt; Konstanten auf Modulebene nutzen msg und werden innerhalb der Komponente aufgelöst. Die Regel nennt auch den jeweiligen Import-Pfad, denn mit dem falschen t-Import bindest du eine globale Instanz, die die App nie lädt.

Interpolation. Nur eine einfache Variable benennt ihren eigenen Slot in der extrahierten Message. Jeder andere Ausdruck wird als {0} extrahiert, mit dem ein Translator nichts anfangen kann – deshalb verlangt die Regel ph(), um ihn zu benennen.

Plurale. other ist immer Pflicht, die Kategorien sind CLDR, und ein Ternary zwischen zwei Strings ist verboten, weil er englische Pluralregeln in die Komponente einbrennt. Falls du Hintergrund brauchst: Was ICU MessageFormat ist erklärt die Syntax, in die die Pluralformen kompiliert werden.

Zahlen und Datum. i18n.number() und i18n.date() – nie toFixed() und nie ein an einen Wert angehängtes Währungssymbol. Lovables eigenes Workspace-Knowledge-Beispiel enthält einen Lokalisierungsabschnitt mit Datumsformat und europäischer Zahlenformatierung. Das ist ein guter Instinkt, aber eine Formatierungsregel, keine Wrapping-Regel. Eine App kann sie perfekt befolgen und trotzdem jede Überschrift auf Englisch ausliefern.

Translator-Kommentare. Kurze Strings mit mehreren Lesarten, nackte Action-Labels und Fachbegriffe bekommen einen comment=, der beschreibt, wo der String erscheint. context= ist für den Fall reserviert, dass derselbe Text an verschiedenen Stellen unterschiedlich übersetzt werden muss.

Katalogpflege. Jeder neue String wird gewrappt und an jede src/locales/*/messages.po mit einem leeren msgstr angehängt, sodass Lingui auf den Quelltext zurückfällt, bis eine Übersetzung eintrifft. Der Agent führt nie lingui extract aus, denn in Lovable gibt es kein Terminal – das übernimmt nach dem Sync eine GitHub Action. Und er ändert nie die Kommentarzeilen #. und #: bestehender Einträge, weil die Extraktion sie neu erzeugt.

Dieser letzte Abschnitt macht die Regeln Lovable-spezifisch. Eine Rules-Datei für Cursor oder Claude Code kann mit „Führe den Linter aus“ enden. Eine Rules-Datei für Lovable kann das nicht – sie muss stattdessen festhalten, was von Hand zu tun ist und was der CI überlassen bleibt.

Was setzt die Regel durch, wenn Lovable nichts ausführen kann?

Der GitHub-Workflow, und nur der GitHub-Workflow. Lovable hat kein Terminal, also gibt es zwischen dem Moment, in dem der Agent ein Literal schreibt, und dem Sync in dein Repository keinen Lint-Schritt. Das ist der strukturelle Unterschied zu IDE-Agents, wo eine Lint-Regel in der CI den Build bei einem hartcodierten String scheitern lässt.

Wenn du dich beim Setup dafür entscheidest, fügt der Skill einen GitHub-Actions-Workflow hinzu. Er läuft bei Pushes auf den Default-Branch – dort landet Lovables Sync –, extrahiert gewrappte Strings in die Kataloge und committet einen Katalog-Sync zurück. Fehlt der GitHub-App die Berechtigung workflows, bittet dich der Skill, die Datei von Hand in GitHub anzulegen. Damit ist der Kreis für alles geschlossen, was der Agent gewrappt hat. Für einen String, den der Agent nicht gewrappt hat, bringt er nichts, denn die Extraktion sieht nur Macros.

Das ehrliche Bild sieht also so aus: Die Regeln in AGENTS.md senken, wie oft ein ungewrapptes Literal auftaucht, der Knowledge-Verweis sichert sie in langen Chats ab, und der Diff in GitHub ist der Ort, an dem du den Rest abfängst. Soll eine Maschine den Rest abfangen, nimm die no-literal-string-Regel von eslint-plugin-i18next als Schritt in denselben Workflow auf. Sie läuft im Repository – dem einzigen Ort, an dem ein Lovable-Projekt überhaupt etwas ausführen kann.

Was passiert mit den Strings, die gewrappt werden?

Sie müssen übersetzt werden – und genau das lohnt sich zu automatisieren, statt jedes Mal neu zu prompten. Die Konvertierung passiert einmalig in der App: Verbinde das Repository, dann konvertiert globalize.now die Codebase einmal und liefert den Katalog als Pull Request, den du reviewst. Danach übersetzen Push-Jobs neue Katalogeinheiten, sobald sie eintreffen – ein <Trans>, das Lovable am Dienstag geschrieben hat, hat seine Übersetzungen also am Mittwoch in einem Pull Request. Kein Dashboard-Schritt, kein Export, keine Freigabe-Queue. Das ausführlichere Argument für dieses Modell steht in eine Lovable-App ohne Dashboard lokalisieren, und der genaue Setup-Weg inklusive GitHub-Anbindung und globalize-Connector steht auf der Lovable-Integrationsseite.

Eine historische Anmerkung, weil sie erklärt, warum dieses Problem für manche Lovable-Builder neu wirkt. Lovalingo hat Lovable-Apps zur Laufzeit im Browser übersetzt – eine neu generierte englische Komponente wurde beim Laden einfach neu übersetzt, das Problem trat also nie zutage. Der Dienst wurde am 31. August 2026 eingestellt, und die Apps, die über die Migrationsanleitung auf committete Kataloge umgezogen sind, stoßen zum ersten Mal auf die vorgelagerte Frage. Das Katalogmodell ist der richtige Trade-off, denn das übersetzte Markup gehört dir und ist indexierbar. Es verlangt aber, dass der Agent übersetzbaren Code schreibt – und dafür musst du ihm sagen, wo die Regeln stehen.

Leg die Regeln dort ab, wo Lovable sie liest

Führe den Skill einmal aus, damit AGENTS.md den vollständigen Block enthält, füge den Zweizeiler als Verweis ins Projekt-Knowledge ein und überlass die Extraktion, die der Editor nicht leisten kann, dem GitHub-Workflow. Wenn du in Lovable baust und die Übersetzung von allem, was im Katalog landet, erledigt haben willst statt sie zu pflegen, gibt die Seite für Vibe Coder den Überblick, und die Preise stehen auf einer eigenen Seite.