Was tatsächlich passiert, wenn du in Lovable mehrsprachig wirst

Du promptest Lovable, eine neue Pricing-Sektion hinzuzufügen. Lovable generiert die Komponente, bindet sie ein und released sie. Deine englische UI ist aktualisiert. Deine messages.po-Kataloge zeigen noch auf den alten Stand. Französische Nutzer sehen den alten Text. Deutsche Nutzer sehen Englisch. Niemand merkt es, bis ein echter Nutzer es meldet.

Das ist kein Lovable-Bug. Es ist eine strukturelle Diskrepanz. Lovable ist auf schnelles UI-Shipping optimiert. i18n verlangt, jeden nutzersichtbaren String über jeden Locale-Katalog hinweg bei jeder Änderung nachzuverfolgen. Diese beiden Ziele stehen in direkter Spannung zueinander.

Das Extraktionsproblem ist fortlaufend, nicht einmalig. Jeder Prompt, den Lovable ausführt, kann neue Strings erzeugen. Jede Iteration ändert bestehenden Content. Es gibt keinen natürlichen Checkpoint, an dem du sagen kannst: „Die Extraktion ist fertig.“

Warum die naheliegenden Lösungen nicht halten

Löst ein einmaliger Extraktionslauf das Problem?

Nein. Du kannst nach deinem ersten Lovable-Build einen String-Extraktionslauf durchführen und saubere PO-Kataloge erstellen. Das funktioniert bis zum nächsten Prompt. Danach vergleichst du manuell Diffs über womöglich Dutzende Komponenten und Dutzende Kataloge. Ein übersehener String in deinem spanischen messages.po-Katalog, und deine spanischen Nutzer sehen englischen Text mitten in einer übersetzten Seite — bekannt als gemischtsprachige UI, eine der vertrauensschädlichsten Erfahrungen, die du ausliefern kannst.

Sind Runtime-Übersetzungstools gut genug?

Runtime-Übersetzer wie Weglot oder per JavaScript eingeschleuste Übersetzungs-Widgets lösen ein anderes Problem. Sie übersetzen Inhalte, nachdem die Seite geladen ist — Nutzer sehen also für einen Sekundenbruchteil die Originalsprache, bevor der übersetzte Content erscheint. Neben der schlechten Nutzererfahrung erzeugt das messbaren Cumulative Layout Shift — ein Core-Web-Vitals-Signal, das Google zum Ranking von Seiten nutzt. Du tauschst ein unsichtbares Wartungsproblem gegen ein sichtbares Performance-Problem.

Reicht es nicht, Lovable per Prompt zu bitten, die Locale-Dateien zu aktualisieren?

Lovable kann in PO-Kataloge schreiben, wenn du es darum bittest. Das Problem: Du musst daran denken, für jeden String, bei jedem Prompt, über jede Locale hinweg zu fragen. Der kognitive Aufwand summiert sich mit jeder weiteren Sprache. Bei vier Locales wird aus jedem UI-Prompt eine vierstufige Koordinationsübung. Genau diese Art von Reibung killt die Geschwindigkeit, die Lovable überhaupt attraktiv macht.

Wie der Lovable-i18n-Kreislauf tatsächlich zusammenbricht

Das Muster ist konsistent genug, um eine erkennbare Form zu haben:

  1. Initiales Setup — Du fügst mehrsprachige Unterstützung hinzu. Es funktioniert. Alles ist übersetzt. Du fühlst dich gut.
  2. Erste paar Releases — Du denkst daran, PO-Kataloge manuell zu aktualisieren. Nervig, aber machbar.
  3. Velocity-Phase — Du fängst an, schneller zu releasen. Die PO-Kataloge hinken zunehmend nach. Du redest dir ein, du holst das nach.
  4. Gemischtsprachige Produktion — Nutzer in nicht-englischen Märkten sehen anfangen, teilweise Englisch zu sehen. Support-Tickets treffen ein. Du verbringst einen ganzen Release-Zyklus nur mit Strings-Suchen.
  5. Refactor-Steuer — Jedes neue Feature hat jetzt versteckte i18n-Kosten, die in der englischsprachigen Version nicht existierten. Deine Release-Geschwindigkeit sinkt.

Über die Refactor-Steuer spricht niemand, wenn Anleitungen zum Thema „So wirst du in Lovable mehrsprachig“ geschrieben werden. Die Guides zeigen das initiale Setup. Sie zeigen nicht, was bei Release 12 passiert.

Die Lösung: i18n fest in deinen Git-Push-Zyklus eingebaut

Die architektonisch richtige Antwort besteht darin, manuelle Schritte vollständig zu entfernen. Wenn Übersetzungen bei jedem Push automatisch aktualisiert werden, verschwindet das Wartungsproblem. Du kannst nicht vergessen, die Extraktion laufen zu lassen, wenn sie sich selbst ausführt.

Der Workflow sieht so aus:

  1. Verbinde dein Lovable-Projekt mit GitHub. Nutze das +-Menü im Chat-Eingabefeld, dann GitHub, dann Connect project.
  2. Füge den lovable-i18n-Skill zu deinem Workspace hinzu. Ö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).
  3. Bitte Lovable, es einzurichten. Füge in den Lovable-Chat ein: 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 mit go für die Standardwerte. Es installiert Lingui, legt PO-Kataloge unter src/locales/{locale}/messages.po an, umschließt Strings mit <Trans>-Makros und fügt einen Sprachumschalter 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, Repository verbinden, die GitHub-App autorisieren, dein Lovable-Repo und den Default-Branch auswählen, Sprachen wählen (50+, RTL inklusive).
  6. Baue in Lovable weiter. Jeder Push löst bei globalize.now einen Übersetzungs-PR mit aktualisierten PO-Katalogen aus; mergen, und die App ist übersetzt released.

Die entscheidende Eigenschaft: Die Connect-and-Sync-Schritte erfordern nach dem Setup nichts mehr von dir. Du führst keinen Befehl aus. Du prüfst kein Dashboard. Du genehmigst keine Übersetzungs-Warteschlange. Neue Strings in deinen Lovable-generierten Komponenten werden beim Push erfasst, übersetzt und als PR zurückgegeben, bevor du den Branch gemergt hast. Das Schritt-für-Schritt-Setup findest du auf der Lovable-Integrationsseite.

Was das für deinen Lovable-Workflow bedeutet

Du musst Lovable nicht aufgeben. Die Architektur ist genau darauf ausgelegt, dass sich deine UI ständig ändert — das ist der ganze Sinn der Sache. Lovable generiert die UI und führt den lovable-i18n-Skill aus; globalize.now übernimmt die Synchronisation.

Lovable generiert Komponenten und wendet den Skill an, wenn du i18n brauchst. globalize.now beobachtet den Output bei jedem Push. Deine Nutzer sehen immer eine vollständige, übersetzte UI, egal wie schnell du releast.

Die Vibe-Coder-Seite von globalize.now enthält mehr Details dazu, wie das Setup speziell für KI-gebaute Apps funktioniert. Wenn du bereits eine Next.js- oder React-App auf Lovable-Basis betreibst, deckt die Entwickler-Seite den technischen Integrationsweg ab.

Für Teams, die bereits mehrere Lovable-Projekte verwalten, bedeutet das Pricing pro Workspace bei globalize.now, dass du nicht pro Sprache oder pro String-Extraktion zahlst — die Sync-Kosten bleiben konstant, während deine App wächst.

Der Wartungsaufwand ist real und summiert sich. Füge den lovable-i18n-Skill in Lovable hinzu (Skills in deinem Workspace öffnen, dann Add, dann Import from GitHub). Siehe den Lovable-Integrationsguide 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