Lovalingo is closing on August 31, 2026 and has stopped new signups. Its runtime translations shut off with the service. If you're migrating, start with the Lovalingo migration guide: translations rebuilt as files in your own repo, and three months of usage free for migrators.

Bei einer Lovable-App ist die eigentliche Entscheidung Runtime-Übersetzung versus committete Übersetzung. Lovalingo und Weglot schleusen Übersetzungen im Browser ein, nachdem die Seite geladen ist. globalize.now generiert Locale-Dateien innerhalb deines Repositorys und hält sie bei jedem Push synchron. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur: Es extrahiert hartcodierte Strings aus deinem KI-generierten Code, legt die Kataloge an und liefert übersetzte Kataloge als Pull Request zurück — ohne manuelle Exporte und ohne Review-Warteschlange. Dieser Guide vergleicht die drei anhand von Funktionsweise, SEO, Installationsweg und Kosten.


Wie funktionieren Lovalingo, Weglot und globalize.now eigentlich?

Sie teilen sich in zwei Lager: Runtime-Widgets und committete Kataloge.

Lovalingo ist eine React-Runtime-Bibliothek. Du installierst @lovalingo/lovalingo und umschließt deine App mit einem Provider; er erkennt Content und übersetzt ihn im Browser, generiert Locale-URLs und hreflang und fügt einen Sprachumschalter ein. Weglot ist ebenfalls eine Runtime-Schicht: Ein JavaScript-Snippet übersetzt deine bestehende Site und liefert Sprachen über Unterverzeichnisse oder Subdomains aus, mit Übersetzungsbearbeitung in Weglots eigener Oberfläche. Beide übersetzen die gerenderte Seite statt deiner Quelle.

globalize.now setzt eine Ebene tiefer an, als Lokalisierungsinfrastruktur. Der lovable-i18n-Skill installiert Lingui, legt einen PO-Katalog pro Locale unter src/locales/[locale]/messages.po an, umschließt Strings mit <Trans>-Makros und fügt eine GitHub Action hinzu. Nachdem du das Repository verbunden hast, gleicht jeder Push neue Strings ab und öffnet einen Pull Request mit aktualisierten Katalogen. Die Übersetzungen liegen als echte Dateien in deinem Repo, nicht in der Runtime eines Anbieters. Wenn du die breitere Kategorie abwägst, geht unser Vibe-Coder-Lokalisierungsguide denselben Trade-off durch.


Was ist der Unterschied zwischen Runtime-Übersetzung und committeten Katalogen?

Runtime-Übersetzung passiert im Browser; committete Übersetzung passiert in deinem Build.

Ein Runtime-Widget liefert deine englische App aus und tauscht Text erst nach dem Rendern der Seite aus. Das ist schnell eingebaut und braucht keine Build-Änderungen, aber der übersetzte Content wird clientseitig zum Anzeigezeitpunkt erzeugt. Ein Ansatz mit committeten Katalogen extrahiert deine Strings in Locale-Dateien, die Teil der Codebase sind, sodass der übersetzte Text ins Markup kompiliert wird, das deine App ausliefert. Diese Dateien gehören dir, sie liegen in der Versionskontrolle und wandern mit dem Repo, wenn du das Tool wechselst.

Das ist auch der Grund, warum Übersetzungen bei KI-gebauten Apps tendenziell abdriften. Jeder Lovable-Prompt kann neue hartcodierte Strings hinzufügen, und ein Runtime-Overlay erfasst nur, was es beim Laden sieht. Die Extraktion fest in den Push-Zyklus einzubauen, hält Kataloge dagegen aktuell. Diesen Fehlermodus haben wir in warum Übersetzungen von Lovable-Apps bei jedem Push kaputtgehen behandelt.


Wie schnell gehen Übersetzungen live?

Minuten im selben Push versus bis zu einem Tag.

Ein Runtime-Service muss deine Site erst verarbeiten, bevor er andere Sprachen ausliefern kann — Lovalingos eigene App sagt dir, dass du bis zu 24 Stunden einplanen musst, bis Übersetzungen und Seiten live gehen. Bei globalize.now läuft die Übersetzung mit dem Push selbst: Sobald du neue Strings pushst, öffnet es einen Pull Request mit aktualisierten Katalogen, typischerweise innerhalb von Minuten, sodass übersetztes Markup im selben Zyklus released wird wie der Code, der es eingeführt hat. Für eine Lovable-App, an der du täglich iterierst, macht das den Unterschied, ob jede Änderung beim Mergen bereits übersetzt ist oder einen Tag hinterherhinkt.


Welcher Ansatz ist besser für SEO bei einer Lovable-App?

Committete Kataloge werden zuverlässiger indexiert als Runtime-Injection.

Suchmaschinen ranken das, was im ausgelieferten HTML steht. Wenn Übersetzungen clientseitig nach dem Rendern eingeschleust werden, sehen Crawler oft nur die ursprüngliche englische Seite, und die Indexierung pro Locale leidet darunter. Weglot mildert das ab, indem es Sprachen über Unterverzeichnisse oder Subdomains mit generiertem hreflang ausliefert, aber die eigene Anleitung weist darauf hin, dass hreflang mit Unterverzeichnis- oder Subdomain-Integration erzeugt wird, nicht bei einem reinen JavaScript-Setup. Lovalingo generiert ebenfalls hreflang und Locale-URLs, doch der übersetzte Text wird weiterhin zur Laufzeit zusammengesetzt.

Mit Lingui, versionierten PO-Katalogen und Locale-Routing ist jede Sprache eine eigenständige, crawlbare Seite, deren übersetztes Markup schon vorliegt, bevor der Browser überhaupt ein Skript ausführt. Für eine Lovable-App, die auch außerhalb der englischsprachigen Suche gefunden werden soll, summiert sich dieser Unterschied über die Zeit. Es gibt außerdem kein Aufflackern von unübersetztem Text und keinen Layout-Shift durch nachträglichen Textaustausch – das hält die Core Web Vitals sauber.


Wie installiert man die einzelnen Lösungen in einem Lovable-Projekt?

Jede Lösung hat einen anderen Einstiegspunkt: einen Provider, ein Snippet oder einen Skill.

Lovalingo ist ein npm-Install plus ein Provider-Wrapper um deine App. Weglot ist ein Script-Tag mit API-Key, konfiguriert im Weglot-Interface. globalize.now installiert sich direkt im Lovable-Editor als Workspace-Skill:

# In Lovable: Skills → Add → Import from GitHub
https://github.com/globalize-now/lovable-i18n

Danach promptest du Lovable direkt:

Set up i18n for my project using the lovable-i18n skill.

Lovable erkennt deinen Stack (Vite SPA oder TanStack Start), installiert Lingui, legt Kataloge an, umschließt die Strings und fügt die GitHub Action hinzu. Du verbindest das Repository mit globalize.now, wählst die Zielsprachen und merged. Baust du dasselbe Repo stattdessen in Cursor oder Claude Code? Führe npx skills add globalize-now/globalize-skills im verbundenen Repo aus für das komplette Bundle. Die vollständige Anleitung findest du auf der Lovable-Integrationsseite.


Was kosten Lovalingo, Weglot und globalize.now?

Die drei Anbieter messen unterschiedlich: Besucher, Wörter und Zeichen.

Lovalingo bietet eine kostenlose Stufe bis 500 Besucher, danach wechselt es zu besucherbasierter Preisgestaltung. Weglot startet kostenlos für 2.000 Wörter und eine Sprache, dann 15 €/Monat für 10.000 Wörter und eine Sprache und 29 €/Monat für 50.000 Wörter und drei Sprachen; die Wort-Limits sind feste Kontingente statt monatlich erneuerbarer Pools. globalize.now kostet 20 €/Monat pro Workspace, inklusive 20 € Übersetzungsguthaben (etwa 200.000 Wörter) pro Monat, danach tokenbasierte Nutzung zum gleichen Preis pro Zeichen. Es gibt weder Kosten pro Sitzplatz noch pro Sprache, Projekte sind unbegrenzt, und bei der Anmeldung erhältst du 5 € Guthaben ohne Kreditkarte.

Praktisch heißt das: Eine kostenlose Runtime-Stufe ist der reibungsloseste Weg, um eine kleine Site zu testen, während ein zeichenbasierter Workspace-Plan ohne Aufpreis pro Sitzplatz oder Sprache berechenbarer skaliert, wenn eine App weitere Sprachen und Seiten dazubekommt. Wähle das Maß, das zu deinem tatsächlichen Wachstum passt. Für einen tieferen Feature-Vergleich zwischen den Tools sieh dir unsere Vergleiche an.


Welche Lösung solltest du für deine Lovable-App wählen?

Entscheide danach, was dir wichtig ist: schnelle Overlay-Lösung oder Ownership und Indexierung.

Greif zu einem Runtime-Widget wie Lovalingo oder Weglot, wenn du an einem Nachmittag Sprachen an eine Live-Site anflanschen willst und nicht auf Suche außerhalb des Englischen optimierst. Wähle globalize.now, wenn du Übersetzungen willst, die in deinem Repository liegen, als indexierbare Seiten pro Locale ausgeliefert werden und automatisch aktuell bleiben, während du Lovable weiter promptest. Das eine ist eine Übersetzungsschicht über der Seite, das andere ist Lokalisierungsinfrastruktur unterhalb der Codebase. Für eine App, die du in mehrere Märkte ausbauen willst, ist es meist die bessere Position, Kataloge und SEO selbst zu besitzen.


globalize.now behandelt Lovable-i18n als versionierte Kataloge. Füge den lovable-i18n-Skill in deinem Workspace hinzu, führe npx skills add globalize-now/globalize-skills im Repo aus oder sieh dir an, wie es funktioniert auf 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