Veröffentlicht8. Juli 2026

Deine Lovable-App hängt bei SSR im Englischen fest

Wichtigste Erkenntnisse

Neue Lovable-Projekte laufen jetzt auf TanStack Start mit SSR, was den Runtime-Widget-Übersetzungsansatz bricht, den die meisten Guides noch lehren.
Bei SSR rendert der Server zuerst Englisch, sodass clientseitige Widgets Englisch aufblitzen lassen und Crawler die falsche Sprache indexieren.
Committete Lingui-PO-Kataloge rendern die richtige Sprache bereits auf dem Server und liefern dir indexierbare Seiten pro Locale.
Speichere das aktive Locale in einem Cookie, nicht in localStorage, damit der Server es vor dem Rendern auflösen kann.
globalize.now extrahiert Strings, generiert Kataloge und synchronisiert sie bei jedem Push, sodass du Locale-Dateien nie von Hand pflegen musst.

Wenn deine Lovable-App auf Englisch rendert, egal welche Sprache du hinzufügst, liegt die Ursache im Stack-Wechsel: Seit Mitte Mai 2026 laufen neue Lovable-Projekte auf TanStack Start mit serverseitigem Rendering statt der alten React-und-Vite-Single-Page-App. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die zu diesem neuen Stack passt, indem sie deine Strings in versionierte Lingui-PO-Kataloge extrahiert, sodass die richtige Sprache schon auf dem Server gerendert wird, statt erst im Browser ausgetauscht zu werden. Die Lösung ist nicht noch ein Widget. Sie besteht darin, die Übersetzung in dein Repo zu verlagern, wo der Server sie rendern und Suchmaschinen sie indexieren können.

Warum ist es plötzlich schwieriger geworden, deine Lovable-App zu lokalisieren?

Weil sich der Boden unter dem alten Ratschlag verschoben hat. Die meisten Anleitungen zum „Lovable-App übersetzen“ gehen von einer clientseitig gerenderten Single-Page-App aus, bei der ein Widget das DOM nach dem Laden umschreiben kann, ohne dass es jemand merkt. Diese Annahme stimmt für neue Projekte nicht mehr.

Lovable hat neue Projekte auf TanStack Start mit SSR umgestellt, damit Crawler bei der ersten Anfrage vollständig gerendertes HTML erhalten, ganz ohne JavaScript-Ausführung. Das ist ein echter SEO-Gewinn, kehrt aber die Reihenfolge um, in der Übersetzung funktionieren muss. Wenn die erste Antwort bereits gerendert ist, kommt eine nachträgliche Übersetzung im Browser zu spät.

Wenn du deine App in den letzten Monaten gebaut und ein Runtime-Übersetzungswidget eingebunden hast, siehst du genau dieses Symptom: kurz Englisch, dann der Austausch. Die Lovable-Integration für globalize.now gibt es genau dafür – um das auf der Ebene zu lösen, wo es hingehört.

Was hat sich beim Wechsel zu TanStack Start bei Lovable eigentlich geändert?

Das Rendering-Modell hat von clientseitig auf serverseitig gewechselt. Vorher erzeugte Lovable Single-Page-Apps mit React und Vite, ausgeliefert als statische Dateien und komplett im Browser gerendert. Jetzt bildet TanStack Start die Basis, ein Full-Stack-React-Framework mit SSR, SSG und CSR pro Route sowie Server-Funktionen direkt neben den Komponenten.

Für die Lokalisierung zählen drei Dinge. Erstens: HTML entsteht auf dem Server, bevor es den Browser erreicht, die Sprache wird also serverseitig entschieden. Zweitens: Das Routing unterstützt jetzt echte URLs pro Locale. Drittens: Alles, was sich zur Sprachauswahl auf browserseitige APIs verlässt, läuft erst, nachdem der Server sich bereits auf eine Sprache festgelegt hat.

Genau der dritte Punkt ist die Ursache der meisten kaputten Setups. Ein in localStorage gespeichertes Locale ist für den Server unsichtbar, sodass der Server die Standardsprache rendert und der Client sie erst einen Moment später korrigiert.

Warum lassen Runtime-Übersetzungswidgets bei SSR kurz Englisch aufblitzen?

Weil sie erst übersetzen, nachdem der Server bereits Englisch gesendet hat. Auf dem neuen Stack läuft es so ab: Der Server rendert HTML in der Standardsprache, der Browser stellt es dar, dann lädt das JavaScript des Widgets und schreibt den Text um. Die Lücke zwischen Darstellung und Umschreiben ist das Aufblitzen von Englisch – und das ist inzwischen strukturell bedingt, kein Tuning-Problem.

Die SEO-Kosten sind schlimmer als das kurze Aufblitzen. Ein Crawler liest die erste Antwort und zieht weiter. Erscheint der übersetzte Text erst, nachdem clientseitiges JavaScript gelaufen ist, indexiert der Crawler für jedes Locale Englisch, und du bekommst keine Seiten pro Sprache, die ranken könnten. Der ganze Grund, warum Lovable auf SSR und indexierbares HTML umgestiegen ist, wird durch Übersetzung im Browser wieder zunichtegemacht.

Versionierte Kataloge vermeiden das von Grund auf. Wenn die Übersetzungsstrings in deinem Repo liegen, rendert TanStack Start das angeforderte Locale auf dem Server, sodass die erste Antwort bereits korrekt ist. Das ist der dauerhafte Unterschied zwischen Infrastruktur, die in deiner Codebase lebt, und einem Widget, das nur obenauf läuft – und genau deshalb passen Runtime-Tools wie Weglot besser zum alten SPA-Modell als zum neuen. Eine ausführlichere Behandlung des Sync-Problems findest du unter Warum Lovable-Übersetzungen bei jedem Push kaputtgehen.

Wie machst du eine TanStack-Start-Lovable-App mehrsprachig?

Verlagere die Übersetzung auf den Server und halte die Kataloge in deinem Repo. Konkret sind das vier Schritte auf dem neuen Stack, und keiner davon erfordert manuelles Bearbeiten von Locale-Dateien.

Füge den Skill lovable-i18n hinzu und lass Lovable die i18n-Verkabelung übernehmen. Füge in deinem Lovable-Workspace den Skill lovable-i18n hinzu und weise Lovable dann per Prompt an, die Internationalisierung einzurichten. Lovable installiert Lingui, extrahiert deine hartcodierten UI-Strings in Message-Kataloge und konfiguriert den Provider. Außerhalb des Editors installierst du dasselbe Setup mit npx skills add globalize-now/globalize-skills (füge --all hinzu, um es für alle Agents zu installieren).
Route Locales mit TanStacks optionalem Path-Parameter. TanStack Router verwendet {-$locale} für optionale Path-Parameter. Eine Route wie /{-$locale}/about matcht also sowohl /about für deine Standardsprache als auch /es/about für Spanisch. So bekommt jede Sprache eine eigene, crawlbare URL – statt einer einzigen URL, deren Text sich nur im Browser ändert.
Löse das Locale auf dem Server auf, nicht in localStorage. Speichere die aktive Sprache in einem Cookie, damit der SSR-Handler sie aus dem Request lesen kann. Bei Lingui ruft der Server setupLocaleFromRequest() auf, bevor der Router erstellt wird, und die Client-Hydration ruft vor dem Rendern dynamicActivate() mit dem vom Server gelieferten Locale auf. Derselbe Wert auf beiden Seiten bedeutet: kein Hydration-Mismatch, kein Aufblitzen.
Halte die Kataloge in deinem Repo, synchronisiert bei jedem Push. Die PO-Kataloge sind committete Dateien, keine Runtime eines Anbieters. Während du in Lovable weiterbaust und neue Strings entstehen, müssen diese erneut extrahiert und übersetzt werden – und genau das verkommt bei manueller Pflege. Das ist der Job, den globalize.now automatisch übernimmt, sodass die Kataloge ohne manuellen Export-Schritt aktuell bleiben.

// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

Weil das ein echter, schrittweiser Prozess mit committetem Output ist, verhält es sich wie normaler, versionierter Code: überprüfbar in einem Pull Request, diffbar und portabel, falls du Lovable irgendwann verlässt.

Wo fügt sich globalize.now in den i18n-Stack von TanStack Start ein?

Es sitzt eine Ebene unter der Runtime-Bibliothek und eine Ebene über der Übersetzungs-Engine. TanStack Start und Lingui liefern Übersetzungen zur Laufzeit aus; DeepL oder ein LLM erzeugt die Übersetzungen selbst. globalize.now ist die Infrastruktur dazwischen: Es generiert die Schlüssel und die PO-Kataloge und hält sie synchron, damit die Runtime immer etwas Korrektes zum Rendern hat.

Der praktische Effekt für jemanden, der mit Lovable baut: Du kümmerst dich nicht mehr manuell um Locale-Dateien. Du installierst den Skill, gibst Lovable einmal den passenden Prompt, und jeder weitere Push extrahiert neue Strings, füllt die Kataloge und öffnet die Änderung als normalen PR. Kein Umweg über ein Dashboard, kein erneuter Export, keine Drift zwischen dem, was deine App anzeigt, und dem, was in den Katalogen steht.

Die Preisgestaltung besteht aus einem einzigen Plan: 20 € / Monat pro Workspace, inklusive 20 € Übersetzungsguthaben (etwa 200.000 Wörter) pro Monat, danach tokenbasierte Nutzung zum gleichen Preis pro Zeichen. Es gibt keine Kosten pro Nutzer und keine Kosten pro Sprache, und bei der Anmeldung erhältst du 5 € Guthaben ohne Kreditkarte. Eine typische Lovable-App mit fünf Sprachen bewegt sich locker innerhalb dieses Rahmens. Wenn du die Details aus Entwicklersicht willst, gehen die Seiten globalize.now für Entwickler und für Vibe Coder tiefer ins Detail, und die Produktübersicht deckt den Rest des Stacks ab.

Deine Lovable-App bleibt auf Englisch hängen, weil die Übersetzung am falschen Ort passiert – im Browser, nachdem der Server sich bereits auf eine Sprache festgelegt hat. Verlagere sie in dein Repo, und der Server rendert schon beim ersten Request die richtige Sprache. globalize.now übernimmt Extraktion und Synchronisation, sodass du es einmal einrichtest und es bei jedem Push aktuell bleibt.

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

Probiere globalize.now kostenlos

War das hilfreich?

Häufig gestellte Fragen

Hat Lovable seinen Stack wirklich geändert, und bricht das Übersetzungen?

Ja. Seit Mitte Mai 2026 laufen neue Lovable-Projekte auf TanStack Start mit Server-Side-Rendering statt als React-und-Vite-Single-Page-App. Das bricht Übersetzungen nicht von selbst, aber es bricht den Runtime-Widget-Ansatz, den viele Guides noch empfehlen. Bei SSR sendet der Server zuerst vollständig gerendertes englisches HTML, sodass ein clientseitiges Widget den Text erst nach dem Laden austauscht — das erzeugt kurz aufblitzendes Englisch, und Crawler indexieren die falsche Sprache.

Warum nicht einfach ein Übersetzungs-Widget zu meiner Lovable-App hinzufügen?

Ein Runtime-Widget übersetzt im Browser, nachdem der Server bereits englisches HTML gerendert hat. Auf dem neuen SSR-Stack bedeutet das, dass Besucher:innen kurz Englisch sehen, bevor der Austausch erfolgt, und Suchmaschinen indexieren die englische Version, weil der übersetzte Text in der ersten Antwort nie existiert. Committete Locale-Kataloge rendern die richtige Sprache bereits auf dem Server — es gibt also kein Aufblitzen, und jedes Locale ist eine echte, indexierbare Seite.

Wie funktionieren Locale-URLs in TanStack Start?

TanStack Router verwendet einen optionalen Pfad-Parameter, geschrieben als {-$locale}, sodass eine Route wie /{-$locale}/about sowohl /about für deine Standardsprache als auch /es/about für Spanisch matcht. Das ergibt saubere, sprachspezifische URLs, die ein Crawler separat indexieren kann — genau darum geht es, wenn man die Übersetzung vom Client-Widget auf den Server verlagert.

Wo sollte meine Lovable-App die aktive Sprache bei SSR speichern?

In einem Cookie, nicht in localStorage. localStorage ist auf dem Server nicht lesbar, sodass der Server nicht wissen kann, welche Sprache er rendern soll — das Ergebnis ist bei jedem Laden ein kurzes Aufblitzen der falschen Sprache. Ein Cookie wird mit dem Request gesendet, sodass der SSR-Handler das Locale vor dem Rendern auflösen und denselben Wert dem Client zur Hydration übergeben kann.

Was macht globalize.now konkret für eine Lovable-App?

globalize.now ist KI-gestützte Lokalisierungsinfrastruktur. Es extrahiert hartcodierte UI-Strings aus deiner Lovable-Codebase, generiert Übersetzungsschlüssel und Lingui-PO-Kataloge und hält sie bei jedem Git-Push synchron. Du installierst es als Lovable-Skill und promptest Lovable einmalig, i18n einzurichten; danach liegen die Kataloge in deinem Repo und aktualisieren sich automatisch, während sich deine App weiterentwickelt.

← Zurück zum Blog