Eine Lovable-App richtig mehrsprachig zu machen bedeutet, echte Übersetzungskataloge in dein Repo zu committen und sie automatisch synchron zu halten – nicht ein Übersetzungs-Widget auf die UI zu schnallen. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die deine hartcodierten Strings extrahiert, PO-Kataloge aufsetzt und sie bei jedem Git-Push aktualisiert. Die schnellen Tools liefern dir eine mehrsprachige Demo in Minuten. Sie hinterlassen dir aber auch Übersetzungen, die auseinanderlaufen, ein Layout, das beim Laden hin- und herspringt, und Seiten, mit denen Suchmaschinen ihre Probleme haben. Hier ist das Setup, das auch Release zwölf noch überlebt.

Was bedeutet „mehrsprachig, richtig gemacht“ eigentlich für eine Lovable-App?

Es bedeutet, dass deine Übersetzungen als committete Kataloge in deiner Codebase liegen, im initialen Markup ausgeliefert werden und sich automatisch aktualisieren, wenn sich die App ändert.

In jeder echten mehrsprachigen App gibt es drei Ebenen. Eine i18n-Runtime-Bibliothek liefert den passenden String für das aktive Locale. Übersetzungskataloge enthalten die eigentlichen Übersetzungen. Und irgendetwas muss diese Kataloge aktuell halten, während sich die UI weiterentwickelt. Die meisten Lovable-Anleitungen behandeln die erste Ebene und lassen die dritte aus – genau die, die letztlich zerbricht.

Lovable ist darauf ausgelegt, deine UI schnell zu verändern. Jeder Prompt kann Text hinzufügen, umbenennen oder umstrukturieren. Die mehrsprachige Frage lautet also nicht „Wie übersetze ich die App einmal?“, sondern „Wie halte ich jedes Locale vollständig, während ich weiter prompte?“ Wer das falsch angeht, liefert eine gemischtsprachige UI aus – einer der schnellsten Wege, das Vertrauen in einem nicht-englischsprachigen Markt zu verspielen.

Warum reichen Übersetzungs-Widgets für Lovable-Apps nicht aus?

Sie übersetzen Inhalte erst, nachdem die Seite geladen ist – das tauscht ein unsichtbares Wartungsproblem gegen ein sichtbares Performance- und SEO-Problem.

Laufzeit-Übersetzer wie Weglot, Lovalingo und eingeschleuste Übersetzer-Widgets sind für Lovable meist die erste Antwort, weil sie in Minuten installiert sind und keine Locale-Dateien brauchen. Der Preis dafür zeigt sich später. Der Nutzer sieht kurz die Originalsprache, bevor die Übersetzung einspringt – ein Aufblitzen unübersetzten Inhalts. Dieser Wechsel verschiebt das Layout und erzeugt Cumulative Layout Shift, den Google als Teil der Core Web Vitals misst.

Das tiefere Problem ist die Auffindbarkeit. Wenn der übersetzte Text erst existiert, nachdem clientseitiges JavaScript gelaufen ist, hast du in der Regel eine echte Seite plus browserseitige Übersetzung. Locale-spezifische URLs sind schwach ausgeprägt oder fehlen ganz, weshalb deine spanischen und deutschen Seiten nicht so ranken wie eine wirklich lokalisierte Website. Für ein internes Tool oder eine Wegwerf-Demo kann ein Widget die richtige Entscheidung sein. Für eine App, die du in anderen Märkten gefunden werden willst, ist es das falsche Fundament.

Hält ein einmaliges i18n-Setup eine Lovable-App dauerhaft übersetzt?

Nein. Ein saubérer Extraktionslauf funktioniert genau bis zum nächsten Prompt – dann beginnt die Drift.

Du kannst Lovable, Cursor oder Claude Code bitten, eine ordentliche i18n-Bibliothek einzurichten und jeden String in Übersetzungskataloge zu ziehen. Das funktioniert tatsächlich für den Build, gegen den du es ausführst. Das Problem: es gibt keinen natürlichen Checkpoint, an dem die Extraktion „fertig“ ist. Der nächste Pricing-Abschnitt, der nächste Empty State, das nächste Button-Label kommen alle als neue hartcodierte Strings dazu, und deine Kataloge fallen still und leise zurück.

Die manuelle Alternative – Lovable bei jeder Änderung bitten, jeden Katalog zu aktualisieren – klingt disziplinsätig und bricht in der Praxis zusammen. Du müsstest dir für jeden String, in jeder Sprache, bei jedem Prompt merken, es zu tun. Mal vier Locales genommen, wird jede UI-Änderung zur Koordinationsübung. Genau diese Reibung killt die Geschwindigkeit, die Lovable erst lohnend gemacht hat.

Wie mache ich meine Lovable-App Schritt für Schritt mehrsprachig?

Bevor du startest: Verbinde dein Lovable-Projekt mit GitHub (+-Menü in der Chat-Eingabe, dann GitHub, dann Connect project), erstelle ein globalize.now-Konto (kostenlose Anmeldung, 5 € Startguthaben, keine Kreditkarte), und stelle sicher, dass du Workspace-Owner oder Admin in Lovable bist, damit du den Skill einmal für den ganzen Workspace hinzufügen kannst.

Repo verbinden, den Skill lovable-i18n einmal hinzufügen, dann bei jedem Push den Sync laufen lassen. Hier der vollständige Ablauf.

  1. Verbinde dein Lovable-Projekt mit GitHub. Nutze das +-Menü in der Chat-Eingabe, dann GitHub, dann Connect project. Lovable synchronisiert dein Projekt mit einem echten Repository – genau das macht dauerhaftes i18n erst möglich. Alles Folgende arbeitet auf diesem Repo, nicht in einer Blackbox.
  2. Füge den Skill lovable-i18n zu deinem Workspace hinzu. Lovable unterstützt wiederverwendbare Skills. Öffne Skills in deinem Lovable-Workspace, dann Add, dann Import from GitHub, und füge https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n ein. Bestätigen. Einmal pro Workspace (Workspace-Owner oder Admin erforderlich). Einen Skill hinzuzufügen ist kostenlos und verbraucht kein Guthaben. Du baust stattdessen in Cursor oder Claude Code? Führe npx skills add globalize-now/globalize-skills im verbundenen Repo aus.
  3. Bitte Lovable, es einzurichten. In den Lovable-Chat einfügen: Set up i18n for my project using the lovable-i18n skill. Lovable erkennt deinen Stack (Vite SPA oder TanStack Start), stellt eine Frage (Quellsprache, Zielsprachen, Locale in der URL oder nicht, GitHub Action hinzufügen), antworte go für die Standardwerte. Es installiert Lingui (@lingui/core, @lingui/react, das Vite-Plugin), verdrahtet den Provider, richtet einen PO-Katalog pro Locale unter src/locales/{locale}/messages.po ein, umschließt Strings mit <Trans>-Makros und fügt einen Sprachwechsler hinzu.
  4. Review und Merge. Lovable synchronisiert mit GitHub; prüfe den Diff, merge in deinen Default-Branch.
  5. Verbinde das Repo mit globalize.now. Anmelden, dann Connect repository, die GitHub-App autorisieren, das Lovable-Repo und den Default-Branch auswählen und Sprachen festlegen (über 50, RTL inklusive).
  6. Bau weiter in Lovable. Bei jedem Push öffnet globalize.now einen Übersetzungs-PR mit aktualisierten PO-Katalogen. Merge ihn. Deine App wird übersetzt ausgeliefert. Zwischen den Releases ist von dir sonst nichts weiter nötig.

Entscheidend ist die Eigenschaft in Schritt drei bis sechs: das Setup passiert einmal, und der laufende Sync braucht weder Befehl noch Dashboard noch Review-Warteschlange. Die vollständige Integrations-Anleitung findest du auf der Lovable-Integrationsseite.

Welche i18n-Bibliothek sollte eine Lovable-App verwenden?

Der Skill lovable-i18n installiert Lingui, weil Lovable-Apps Vite-SPA- oder TanStack-Start-React-Projekte sind und Lingui zu diesem Stack passt.

Der Skill verdrahtet @lingui/core, @lingui/react und das Vite-Plugin, richtet PO-Kataloge unter src/locales/{locale}/messages.po ein und umschließt Strings mit <Trans>-Makros. react-i18next und next-intl sind die richtige Wahl für andere React- und Next.js-Setups, aber der Skill installiert sie nicht.

Vermeide es, einen eigenen Übersetzungs-Context zu erfinden oder eine Sprachen-Map hartzucodieren. Am ersten Tag fühlt sich das leichtgewichtiger an, an Tag dreißig wird genau das wieder herausgerissen. Die Entwickler-Seite bei globalize.now zeigt, wie sich die Extraktion auf die jeweilige Bibliothek abbildet, damit du nicht blind entscheidest.

Wie halte ich Übersetzungen synchron, während ich Lovable weiter prompte?

Verlege den Sync in deinen Git-Workflow, damit er nicht vergessen werden kann.

Manuelles i18n scheitert, weil es davon abhängt, dass ein Mensch sich mitten in einem schnellen Build-Zyklus an eine lästige Pflicht erinnert. Infrastruktur nimmt den Menschen aus dem Kreislauf. Wenn der Diff- und Übersetzungsschritt bei jedem Push läuft, wird ein neuer String, den ein Lovable-Prompt erzeugt hat, bei genau diesem Push erfasst, übersetzt und per PR zurückgespielt, bevor der Branch gemergt wird. Es gibt kein Release, bei dem die PO-Kataloge still hinterherhängen, weil es keinen manuellen Schritt gibt, der übersprungen werden könnte.

Das ist der Unterschied zwischen einem Setup und Infrastruktur. Ein Setup ist ein Zustand, den du einmal erreichst. Infrastruktur ist eine Eigenschaft, die bestehen bleibt, während sich alles um sie herum verändert. Für eine App, die du weiterhin in Lovable bearbeitest, willst du die Eigenschaft, nicht den Zustand. Mehr zum KI-gebauten-App-Workflow speziell findest du auf der Vibe-Coder-Seite, und wenn du gerade Tools abwägst, zeigt der Vergleichs-Guide, wo jedes davon im Stack sitzt.

Eine Lovable-App mehrsprachig zu machen ist leicht angefangen und schwer beibehalten. globalize.now übernimmt das Beibehalten. In Lovable fügst du den Skill lovable-i18n über Open Skills hinzu, dann Add, dann Import from GitHub, mit Verweis auf globalize-now/lovable-i18n. In Cursor oder Claude Code führst du npx skills add globalize-now/globalize-skills aus. Siehe die Lovable-Integrationsanleitung oder globalize.now.

globalize.now konvertiert hartcodierte App-Texte in übersetzungsreife Locale-Dateien und hält sie aktuell, während Sie veröffentlichen.

Probiere globalize.now kostenlos