Der beste Weg, eine Lovable-App auf dem klassischen Vite-Stack zu lokalisieren, ist, deine hartcodierten Strings in committete Lingui-PO-Kataloge zu extrahieren – statt ein Runtime-Übersetzungs-Widget draufzusetzen. Deine Lovable-App ist eine client-gerenderte React-SPA, es gibt also kein Server-Rendering, in das man sich einklinken könnte. Die dauerhafte Lösung sind Übersetzungsdateien, die in deinem eigenen Repo liegen und mit deinem Build ausgeliefert werden. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die genau diese Extraktion übernimmt und die Kataloge bei jedem Git-Push synchron hält – einmal eingerichtet, nie wieder manuell an Locale-Dateien herumbasteln.

Auf welchem Stack läuft deine Lovable-App – klassisches Vite oder TanStack Start?

Öffne zuerst deinen Dateibaum, denn Lovable liefert zwei verschiedene Stacks aus, und jeder braucht ein anderes i18n-Setup. Siehst du src/pages/Index.tsx, src/main.tsx und vite.config.ts, läufst du auf dem klassischen Vite-plus-React-SPA-Stack, dem Standard von Lovable. TanStack-Start-Projekte haben stattdessen src/routes/, src/router.tsx, src/routeTree.gen.ts und src/server.ts.

Der Stack wird bei der Projekterstellung festgelegt und lässt sich danach nicht mehr wechseln – diese Entscheidung ist also schon für dich getroffen. Der klassische Vite-Stack rendert vollständig im Browser und ruft standardmäßig keine Daten serverseitig ab. Diese Anleitung behandelt genau diese klassische Vite-SPA. Passen deine Dateien zum TanStack-Start-Layout, folge stattdessen unserer TanStack-Start-i18n-Anleitung für Lovable, denn Server-Rendering verändert, wie Übersetzungen geladen werden.

Warum werden Vite-SPA-Lovable-Apps vom i18n-Tooling übergangen?

Weil sich die Aufmerksamkeit des Tooling-Ökosystems auf Lovables neueren TanStack-Start-plus-SSR-Standard verlagert hat und die klassische Vite-SPA dabei unterversorgt zurückblieb – obwohl sie nach wie vor der verbreitetste Lovable-Stack ist. In den letzten Monaten haben alle Lokalisierungstools, die auf Lovable zielen, darunter Lovalingo, Intlayer und Paraglide, ihre Anleitungen auf TanStack Start mit Server-Side-Rendering umgestellt.

Damit entsteht eine Lücke. Eine client-gerenderte SPA hat reale Einschränkungen, die SSR-Anleitungen ignorieren: Es gibt kein Server-Rendering, um übersetztes Markup einzuschleusen, das gesamte Bundle lädt im Browser, und jedes spät ladende Skript übermalt eine englische UI. Die gute Nachricht: Der klassische Stack hat eine saubere, gut unterstützte Lösung, von der die meisten Builder nie hören, weil die lautesten Tools gerade dem anderen Stack hinterherjagen.

Was ist der Unterschied zwischen committeten Katalogen und einem Runtime-Übersetzungs-Widget?

Committete Kataloge sind Übersetzungsdateien, die in dein Repository eingecheckt und zur Build-Zeit gebündelt werden, während ein Runtime-Widget ein Skript eines Drittanbieters ist, das Text im Browser austauscht, nachdem deine englische UI bereits geladen wurde. Dieser Unterschied entscheidet über drei Dinge, die für eine Vite-SPA wichtig sind.

Erstens Aufblitzen und Layout-Verschiebung: Ein Widget zeigt zunächst Englisch, schreibt es dann um – Nutzer sehen einen sichtbaren Wechsel, und das Layout kann springen. Committete Kataloge rendern die richtige Sprache bereits beim ersten Paint. Zweitens Indexierbarkeit: Strings, die in deinem Build enthalten sind, gehören zu deinem Quellcode, während Widget-Text erst spät eingeschleust wird und für Crawler schwerer lesbar ist. Drittens Eigentümerschaft: Committete Kataloge sind deine eigenen Dateien in deinem Repo – nichts Externes muss online bleiben, damit deine App weiterhin Deutsch oder Japanisch spricht.

Wie fügst du i18n zu einer Lovable-Vite-App mit Lingui hinzu?

Füge Lingui als i18n-Ebene hinzu, umschließe deine Strings und lass sein Vite-Plugin die Kataloge kompilieren. Lingui ist ein schlankes i18n-Framework mit dediziertem Vite-Plugin und PO-basiertem Katalogformat – genau das, was eine client-gerenderte SPA braucht.

Installiere zuerst die Pakete. Lingui teilt sich in CLI, Vite-Plugin und React-Runtime auf:

npm install --save-dev @lingui/cli @lingui/vite-plugin @rolldown/plugin-babel
npm install @lingui/core @lingui/react

Registriere als Nächstes das Plugin in vite.config.ts und füge eine lingui.config.ts hinzu, die auf deinen Quellcode- und Locales-Ordner zeigt:

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { lingui } from "@lingui/vite-plugin";

export default defineConfig({
  plugins: [react(), lingui()],
});

// lingui.config.ts
import { defineConfig } from "@lingui/cli";

export default defineConfig({
  locales: ["en", "de", "fr"],
  sourceLocale: "en",
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

Umschließe dann deinen hartcodierten JSX-Text mit dem Trans-Makro, statt ihn als nackten String stehen zu lassen:

// before
<h1>Create your account</h1>

// after
import { Trans } from "@lingui/react/macro";
<h1><Trans>Create your account</Trans></h1>

Jetzt extrahieren. Die CLI scannt dein src-Verzeichnis und schreibt pro Locale einen PO-Katalog, zum Beispiel src/locales/en/messages.po:

npx lingui extract

Fülle die msgstr-Felder für jede Sprache aus, oder überlass diesen Schritt einer automatisierten Ebene (siehe nächster Abschnitt). Einen separaten Compile-Befehl brauchst du nicht, weil @lingui/vite-plugin die PO-Kataloge während Entwicklung und Build laufend selbst kompiliert.

Füge zum Schluss einen Sprachumschalter hinzu, indem du zur Laufzeit ein Locale aktivierst:

import { i18n } from "@lingui/core";
i18n.activate("de");

Das ist der gesamte Ablauf für den klassischen Vite-Stack: installieren, umschließen, extrahieren, übersetzen, umschalten. Alles außer den Übersetzungen selbst liegt in deinem Repo.

Wie automatisiert globalize.now das bei jedem Push?

globalize.now entfernt die manuellen Extrahieren-und-Ausfüllen-Schritte, indem es dein Repo beobachtet und diese bei jedem Git-Push für dich erledigt. Es findet neu hartcodierte Strings in deiner Lovable-Codebase, generiert die Schlüssel und PO-Einträge, die Lingui erwartet, erzeugt die Übersetzungen und committet die aktualisierten Kataloge zurück – sodass dein src/locales-Ordner immer aktuell ist, ohne dass du Befehle ausführen musst.

Verbinde das Repository einmal auf globalize.now, dann beginnt die Beobachtung. Um es stattdessen direkt aus deinem Editor einzurichten, installiere die Skills:

npx skills add globalize-now/globalize-skills

Konkret in Lovable: Füge den Skill lovable-i18n in deinem Workspace hinzu und weise Lovable dann per Prompt an, i18n einzurichten. Die Runtime bleibt Lingui, an der Art, wie deine App rendert, ändert sich also nichts. Was sich ändert, ist, dass du dich nicht mehr manuell um Locale-Dateien kümmern musst. Das ist dasselbe Einmal-einrichten-bei-jedem-Push-synchronisieren-Modell, um das unser Vibe-Coder-Workflow und Entwickler-Setup aufgebaut sind.

Die Preisgestaltung ist für Solo-Builder unkompliziert: 20 € pro Monat pro Workspace, ohne Kosten pro Nutzer und ohne Kosten pro Sprache, plus die Übersetzungen, die du tatsächlich nutzt. Neue Workspaces erhalten 5 € Startguthaben ohne Kreditkarte – genug, um eine kleine App vollständig zu übersetzen.

Solltest du stattdessen ein Runtime-Widget verwenden? Die Lehre aus Lovalingo

Nicht, wenn deine Übersetzungen einen einzelnen Anbieter überdauern sollen. Ein Runtime-Übersetzungs-Widget ist zunächst bequem, macht deine App aber davon abhängig, dass der Server eines anderen online bleibt – und diese Abhängigkeit hat einen ganz realen Ausfallmodus.

Lovalingo, ein bei Lovable-Buildern beliebtes Runtime-Widget, hat angekündigt, am 31. August 2026 zu schließen – ohne neue Anmeldungen und ohne benannten Nachfolger. Die eigene Migrationsanleitung des Anbieters rät Nutzern, zu projekteigener Internationalisierung zu wechseln – genau der Ansatz mit committeten Katalogen aus dieser Anleitung. Wenn der Anbieter eines Widgets abschaltet, hören die eingeschleusten Übersetzungen auf zu existieren, und die UI fällt auf Englisch zurück. Dateien in deinem Repo tun das nicht. Bist du bereits auf ein Widget umgestiegen, führt dich unsere Migrationsanleitung zur Lovalingo-Abschaltung durch den Umzug, und das größere Problem, dass Übersetzungen bei jedem Push kaputtgehen erklärt, warum committete Kataloge bei KI-gebauten Apps die Nase vorn haben.

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

Probiere globalize.now kostenlos