Wie fügst du den lovable-i18n-Skill zu einem Lovable-Workspace hinzu?

Du fügst ihn von GitHub hinzu: Öffne Einstellungen, dann Skills, dann Hinzufügen, dann Von GitHub importieren, und zeig Lovable auf das globalize-now/lovable-i18n-Repository. Lovable lädt es herunter, validiert es und veröffentlicht es im Workspace, wo jedes Projekt es nutzen kann. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur: Sie erzeugt die Schlüssel und Übersetzungsdateien, und die Runtime-Bibliothek in deiner App liefert sie aus. Der Skill ist der Weg, wie das ankommt, ohne den Lovable-Editor zu verlassen — und der Grund, warum überhaupt kein Dashboard im Spiel ist.

Was genau ist ein Lovable-Skill?

Ein Skill ist ein kurzes, benanntes Playbook, das du einmalig auf Workspace-Ebene speicherst. Er besteht aus drei Teilen: einem festen Namen in Kleinbuchstaben, einer Beschreibung, die Lovable mitteilt, wann er geladen werden soll, und Markdown-Anweisungen, denen Lovable folgt, sobald er angewendet wird.

Die entscheidende Eigenschaft ist, dass Skills bei Bedarf geladen werden. Workspace-Wissen funktioniert anders – das steht immer im Kontext, weshalb dort Coding-Standards und Markenregeln hingehören. Ein Skill tritt der Konversation nur bei, wenn die Anfrage zu seiner Beschreibung passt, sodass ein Workspace viele fokussierte Skills enthalten kann, ohne dass sie unzusammenhängende Arbeit belasten.

Du kannst einen gezielt aufrufen, indem du / in das Chat-Eingabefeld tippst und ihn auswählst, oder Lovable ihn automatisch anwenden lassen, wenn dein Prompt passt. Betrachte den Skill als das Wie und deinen Prompt als das Was.

Sie sind zudem portabel. Lovable verwendet dieselbe SKILL.md-Struktur wie Anthropics Agent-Skills-Konvention, weshalb sich ein für ein Tool geschriebener Skill ohne Übersetzung ins andere importieren lässt. Das ist kein Nebendetail für die Lokalisierung: Es bedeutet, dass dieselben Anweisungen, die i18n innerhalb von Lovable aufbauen, in ein Repository wandern können, das du später in Claude Code oder Cursor öffnest.

Warum läuft eine Lovable-App nur auf Englisch?

Weil der generierte Code keine Locale-Schicht hat, die etwas anderes ausliefern könnte. Wenn du Lovable nach einer Preisseite promptest, schreibt es die Überschrift direkt als Literal in der Sprache des Prompts in die Komponente. Jeder Button, jeder Empty State, jeder Toast und jede Validierungsmeldung landet auf dieselbe Weise.

Bittet man den Agent später, „die App zu übersetzen“, kommt nur ein Halb-Ergebnis heraus: Die Screens, die er sich gerade angesehen hat, werden ausgetauscht, und das nächste Feature, das du baust, kommt wieder auf Englisch an. Wir haben dieses wiederkehrende Muster ausführlich dokumentiert in warum Lovable-Übersetzungen wegdriften, und der Mechanismus hat sich nicht geändert — der Agent löst den Prompt vor sich, nicht die Architektur dahinter.

Die Lösung ist strukturell und einmalig: Gib den Strings Schlüssel, lege die Übersetzungen in Dateien ab, und lass die Runtime aus diesen Dateien lesen. Ein Skill ist dafür ein guter Träger, gerade weil er ein fester Ablaufplan ist und kein Prompt, den man zweimal richtig formulieren muss.

Was installiert der lovable-i18n-Skill?

Lingui v6, mit PO-Katalogen unter src/locales/[locale]/messages.po, Trans-Makros für die Extraktion, einer Sprachumschalter-Komponente und einer GitHub Action. Der Skill erkennt, welchen Stack dein Projekt verwendet, und generiert entsprechend das Scaffolding — Vite SPA oder TanStack Start, beide werden von Lovable erzeugt.

Diese Stack-Erkennung ist wichtiger, als es klingt. Lovables Standard-Stack ist inzwischen auf TanStack Start mit Server-Rendering umgestiegen, und die korrekte i18n-Einbindung unterscheidet sich zwischen einer client-gerenderten SPA und einer server-gerenderten App. Den server-gerenderten Fall haben wir separat im TanStack-Start-Guide behandelt; der Skill wählt den richtigen Pfad, sodass du nicht wissen musst, welchen Stack du bekommen hast.

Was der Skill nicht installiert, ist eine Laufzeit-Abhängigkeit von uns. Die Kataloge sind Dateien in deinem Repository. Würdest du globalize.now morgen entfernen, rendert eine Lingui-App mit committeten PO-Dateien weiterhin jede Sprache, die sie bereits hat.

Wie importierst du den Skill?

Vier Schritte, einmal pro Workspace.

1. Verbinde das Lovable-Projekt mit GitHub. Nutze das +-Menü im Chat-Eingabefeld, wähle GitHub und dann Connect project. Die Kataloge brauchen ein echtes Repository, in dem sie leben können.
2. Importiere den Skill. Settings, dann Skills, dann Add, dann Import from GitHub, verweisend auf https://github.com/globalize-now/lovable-i18n. Die SKILL.md liegt im Root des Repositorys — das Layout, das Lovable erwartet, wenn du ihm eine Whole-Repository-URL gibst. Ein Unterverzeichnis in einem größeren Skills-Repository funktioniert ebenfalls, per tree- oder blob-URL.
3. Füge das globalize MCP hinzu. Öffne Connectors, wähle Custom MCP und füge https://api.globalize.now/mcp hinzu. Der Skill führt dich durch den Sign-in-Schritt, wenn es dazu kommt.
4. Prompte Lovable. Bitte es, den lovable-i18n-Skill und das globalize MCP zu nutzen, um i18n einzurichten und die App zu übersetzen.

Zwei Einschränkungen solltest du vorher kennen. Das Erstellen, Bearbeiten, Löschen und Importieren von Custom-Workspace-Skills ist auf Workspace-Owner und -Admins beschränkt — Editoren können jeden Skill sehen und aufrufen, aber keinen hinzufügen. Und das Hinzufügen eines Skills über Settings verbraucht keine Credits; die Nachricht, die ihn später nutzt, wird wie jede andere Build-Nachricht abgerechnet.

Die vollständige Schritt-für-Schritt-Anleitung mit den genauen URLs findest du auf der Lovable-Integrationsseite.

Welches MCP ist das, und welches ist es nicht?

Das ist der verwirrende Teil, und wer es verwechselt, verschwendet einen Nachmittag.

Lovable stellt zwei MCP-Oberflächen bereit, die in entgegengesetzte Richtungen zeigen. Der Lovable-MCP-Server unter mcp.lovable.dev erlaubt einem externen Agent — ChatGPT, Claude, Cursor, VS Code — deine Lovable-Projekte von außerhalb zu erstellen und zu bearbeiten. Chat-Connectors, unter Connectors als Custom MCP hinzugefügt, sind das Gegenteil: Sie erlauben dem Lovable-Agent, während du baust, nach außen zu einem externen Tool zu greifen.

Das globalize MCP ist die zweite Art. Du gibst dem Lovable-Agent die Fähigkeit, dein Lokalisierungsprojekt zu erstellen, die Kataloge zu übersetzen und das Repository zu verbinden, ohne dass du dafür ein zweites Produkt öffnen musst. Lovables eigene Dokumentation macht diese Unterscheidung explizit — ein gutes Zeichen dafür, dass sie regelmäßig für Verwirrung sorgt.

Die praktische Konsequenz: Wenn du dich dabei wiederfindest, eine URL in Claude oder Cursor einzufügen, um das hinzubekommen, bist du auf der falschen Oberfläche. Alles hier passiert innerhalb des Lovable-Editors.

Was passiert nach dem ersten Setup?

Der Skill baut das Scaffolding auf, und der Diff synct mit GitHub. Prüfe ihn wie jede andere Änderung — Lingui-Konfiguration, die PO-Kataloge, die Komponenten-Edits, die Strings in Trans-Makros einbetten, den Sprachumschalter — und merge ihn dann in deinen Default-Branch.

Danach ist die Konvertierung erledigt. Sie ist einmalig und findet in der App statt: Du hast das Repository verbunden, und globalize.now hat die Codebase einmal konvertiert, um den Katalog zu erzeugen. Von da an übersetzen Push-Jobs neue Katalog-Einheiten und liefern sie als Pull Request, den du mergst. Du promptest Lovable ganz normal weiter; neue Strings landen im Katalog, statt sich als unübersetzte Literale anzusammeln.

Es gibt keinen Export-Schritt, keinen Import-Schritt und keinen Screen, auf dem jemand Strings einzeln abnickt. Das ausführlichere Argument dafür, warum das wichtig ist, findest du unter Lokalisierung einer Lovable-App ohne Dashboard.

Warum ein Skill statt eines Übersetzungs-Widgets?

Weil ein Widget und ein Katalog unterschiedliche Artefakte erzeugen — und nur eines davon gehört dir.

Ein Laufzeit-Widget — das Weglot-Modell — injiziert JavaScript, das Text im Browser umschreibt, nachdem die Seite geladen wurde. Du bekommst kurz einen englischen Flash, ein Layout, das sich verschiebt, wenn sich die String-Länge ändert, und eine einzige englische Seite im Index, während die Übersetzung client-seitig passiert, wo ein Crawler sie nicht verlässlich sieht. Es funktioniert auf jeder Site, was auch sein eigentliches Verkaufsargument ist, und es ist eine vernünftige Wahl für eine Marketing-Seite, deren Code du nicht kontrollierst.

Ein committeter Katalog ist der gegenteilige Trade-off. Er erfordert Code-Zugriff, den du hast, und im Gegenzug rendert das übersetzte Markup aus deinem eigenen Repository, mit einer indexierbaren Seite pro Sprache. Lovalingo hat speziell für Lovable auf dem Laufzeit-Modell aufgebaut und wurde am 31. August 2026 eingestellt; wenn du davon wegziehst, deckt der Migrations-Guide den Export deiner bisherigen Daten ab. Diese Einstellung ist zugleich das klarste Argument für die dateibasierte Form: PO-Kataloge in deiner Git-Historie hängen nicht davon ab, dass ein Unternehmen noch existiert.

Wenn du die End-to-End-Version willst, die auf das Ergebnis statt auf den Mechanismus zielt, starte mit eine Lovable-App mehrsprachig machen. Wenn du wissen willst, was es kostet, bevor du anfängst, findest du auf der Preisseite die aktuellen Pläne.

Einmal hinzufügen

Der Import ist eine einmalige Workspace-Aktion, und er ist kostenlos. Danach ist i18n etwas, das du im Chat-Eingabefeld anfragst wie jedes andere Feature, und die Übersetzungen kommen als Dateien an, die dir gehören.