Wie lokalisierst du eine Lovable-App ohne Dashboard?

Du lokalisierst eine Lovable-App ohne Dashboard, indem du jeden Teil des Workflows im Repository hältst: Message-Kataloge als committete Dateien, eine Konfigurationsdatei, die deine Locales benennt, und einen CLI-Schritt in deinem Build, der sie kompiliert. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die diesen Kreislauf für dich übernimmt: Strings aus deiner Codebase extrahieren, Schlüssel und Locale-Dateien generieren und Übersetzungen bei jedem Git-Push synchron halten. Nichts in dieser Kette braucht eine Browser-Oberfläche – was mehr zählt, als es klingt, wenn derjenige, der deinen Code schreibt, ein Agent ist.

Warum bringt ein Dashboard einen KI-gebauten Workflow ins Wanken?

Weil dein Agent keines öffnen kann. Lovable, Cursor, Claude Code und Copilot arbeiten alle auf denselben zwei Oberflächen: Dateien in einem Repository und Befehle im Terminal. Ein Dashboard ist keines von beidem.

Diese Lücke ist inzwischen eine dokumentierte Grundannahme und keine bloße Vorliebe mehr. AGENTS.md, die Konvention, mit der man Coding-Agents erklärt, wie ein Projekt funktioniert, wurde im Dezember 2025 zusammen mit dem Model Context Protocol an die Agentic AI Foundation der Linux Foundation übergeben. Laut der offiziellen Ankündigung der Linux Foundation hatten zu diesem Zeitpunkt bereits über 60.000 Open-Source-Projekte das Format übernommen, über mehr als zwanzig KI-Coding-Tools hinweg. Die ganze Prämisse dabei: Projektanweisungen gehören in eine Datei, die der Agent lesen kann.

Übersetzungsstatus, der hinter einem Login liegt, fällt aus dieser Prämisse heraus. Wenn dein Agent deiner Lovable-App einen neuen Button hinzufügt, kann er den String ergänzen. Er kann sich aber nirgendwo einloggen und ein Übersetzungsraster abgleichen. Also geht der String auf Englisch live, die Abweichung summiert sich, und du erfährst davon erst von einer Nutzerin aus Deutschland.

Es gibt noch ein zweites, leiseres Problem. Wenn Korrekturen nur in der Oberfläche eines Anbieters existieren, ist das Repository nicht mehr die Wahrheit darüber, was deine App tatsächlich sagt. Zwei Quellen der Wahrheit, von denen eine dein Tooling nicht einsehen kann, ist ein Debugging-Problem, das nur auf eine Deadline wartet.

Wie sieht ein Lovable-Setup ohne Dashboard konkret aus?

Vier Dateien und ein Befehl in deinem Build. Lovable-generierte Apps kommen als React-Anwendungen – entweder auf dem klassischen Vite-Stack oder auf TanStack Start mit serverseitigem Rendering – und beide haben dieselbe Grundstruktur.

1. Locales in der Konfiguration benennen. Eine committete Datei ist die Liste, aus der jede andere Schicht liest.

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

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

2. Nachrichten in Kataloge extrahieren. lingui extract scannt deinen Quellcode und schreibt pro Locale einen .po-Katalog. Es führt das Ergebnis mit dem zusammen, was bereits auf der Festplatte liegt – bestehende Übersetzungen überleben also einen erneuten Lauf. Genau diese Eigenschaft macht es sicher, den Vorgang in eine automatisierte Schleife einzubauen.

npx lingui extract

3. Vor dem Build kompilieren. lingui compile wandelt die Kataloge in Runtime-Module um. Das Flag --strict lässt den Build fehlschlagen, wenn eine Übersetzung fehlt – so wird ein stiller Englisch-Fallback in Produktion zu einem roten Build, den du zuerst siehst.

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. Die Synchronisation bei jedem Push laufen lassen. Eine Locale hinzuzufügen sollte eine Bearbeitung des locales-Arrays sein, kein Support-Ticket. globalize.now beobachtet das Repository, extrahiert Strings, die der Agent eingebaut hat, generiert die Schlüssel und Katalog-Einträge für jede Locale und committet sie zurück. Die Kataloge kommen als Diff in einem Pull-Request an – reviewbar wie jede andere Änderung.

Die vollständigen Schritt-für-Schritt-Anleitungen je Stack findest du im Lovable-Vite-Guide und im TanStack-Start-Guide.

Was passiert mit dashboardgemanagten Übersetzungen, wenn der Anbieter dichtmacht?

Sie verschwinden mit dem Anbieter. Das ist diesen Monat keine Hypothese: Lovalingo, ein Runtime-Übersetzungsdienst für Lovable und andere KI-Builder-Apps, schließt am 31. August 2026 um 23:59 MESZ. Neue Projekte und Abos sind bereits gestoppt, und die eigene Abschaltungsseite des Unternehmens rät Kunden, projekteigene Internationalisierung parallel zum Dienst zu implementieren, bevor sie ihn entfernen, und danach Locale-Routen, Fallbacks, kanonische URLs, hreflang und Sitemap-Ausgabe zu prüfen.

Das ist ein Anbieter, der treffend den Unterschied zwischen Mieten und Besitzen eines Workflows beschreibt.

Die letzte Zeile hat eine SEO-Konsequenz, die über die Anbieterfrage hinausreicht. Übersetzungen, die erst nach dem Laden eingefügt werden, stehen nicht zuverlässig in dem HTML, das ein Crawler liest. Kataloge, die in deinen Build kompiliert sind, stehen darin.

Wie prüfst du, ob deine Lovable-App keine Dashboard-Abhängigkeit hat?

Drei Checks, jeder davon scheitert laut und deutlich.

Das Netzwerk prüfen. Lade deine App mit geöffneten DevTools, filtere nach Scripts und achte auf Anfragen an die Domain eines Übersetzungsanbieters. Wenn ein Drittanbieter-Skript erst laden muss, bevor deine deutsche Seite auch deutsch wirkt, hängt deine deutsche Seite von der Verfügbarkeit eines anderen Dienstes ab.

Das Repository prüfen. Für jede Locale in deiner Konfiguration sollte eine Katalogdatei auf der Festplatte existieren und von Git verfolgt werden. Führe git ls-files "src/locales/**" aus und zähle. Leere oder fehlende Kataloge bedeuten, dass die Strings woanders liegen.

Prüfe den Build. Kompiliere mit --strict in der CI. Eine fehlende Übersetzung sollte ein Deployment stoppen. Läuft dein Build durch, obwohl ein Locale unvollständig ist, taucht die Lücke als englischer Text in einer nicht-englischen UI auf – genau das melden Nutzer:innen als „die Seite ist kaputt“.

Führe alle drei Checks gegen ein Preview-Deployment aus, bevor du einen bestehenden Anbieter entfernst – nicht danach. Auch Lovalingos eigene Checkliste vor der Entfernung sagt dasselbe: Den alten Dienst installiert lassen, bis der Ersatz auf echten Locale-Routen getestet wurde. Unser Lovalingo-Vergleich behandelt den Migrationspfad direkt.

Wo passt globalize.now hin, wenn es kein Dashboard gibt?

In die Schicht zwischen deiner i18n-Runtime und deiner Übersetzungs-Engine. Bibliotheken wie Lingui, i18next und next-intl liefern die Übersetzungen zur Laufzeit aus. Engines wie DeepL und GPT-Übersetzung erzeugen den Text. globalize.now generiert und pflegt das, was in der Mitte liegt: die Schlüssel und Locale-Dateien, immer aktuell zum Code.

Genau diese Schicht musste bisher jemand per Klick in einer Oberfläche pflegen – deshalb ist das Entfernen der Oberfläche eine Änderung des Workflows und kein Feature-Verlust. Das Setup läuft einmalig: Verbinde das Repository mit globalize.now, und die Konvertierung kommt als Pull-Request. In deinem Editor ist dasselbe Setup ein einziger Befehl:

npx skills add globalize-now/globalize-skills

Innerhalb von Lovable installiert sich dieselbe Fähigkeit als In-Editor-Skill, sodass der Agent, der deine App baut, sie direkt aufrufen kann. Der Starter-Plan kostet 20 € pro Monat pro Workspace, inklusive eines monatlichen Übersetzungsguthabens von 20 € (rund 200.000 Wörter). Verbrauch darüber hinaus wird zum gleichen Preis pro Zeichen abgerechnet. Keine Gebühren pro Sitzplatz, keine Gebühren pro Sprache, und ein Anmelde-Guthaben von 5 € ohne Kreditkarte. Sprachen und Projekte sind innerhalb eines einzigen Workspace unbegrenzt – das ist der Teil, der zählt, wenn du eine fünfte Locale hinzufügst statt eines fünften Sitzplatzes.

Mehr zum umgebenden Workflow für Vibe Coder und Entwickler, sowie das Lovable-spezifische Setup auf der Lovable-Integrationsseite.

Die Kurzfassung

Die Übersetzungen deiner Lovable-App sollten Dateien sein, die dir gehören, in einem Repository, das dein Agent lesen kann, kompiliert von deinem eigenen Build. globalize.now hält diese Dateien bei jedem Git-Push aktuell.