Wie lokalisierst du eine v0-App ohne Dashboard?

Du lokalisierst eine v0-App, indem du das GitHub-Repository, in das v0 bereits schreibt, als Zuhause für deine Übersetzungskataloge behandelst und sie dort als committete Dateien hältst. Genau diese eine Entscheidung macht ein Dashboard überflüssig statt nur optional. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur: Sie erzeugt die Schlüssel und Locale-Dateien, und welche Runtime-Bibliothek du auch verwendest, liefert sie aus. v0 gibt dir von Anfang an eine vollständige Next.js-Codebase statt einer gehosteten Seite, also steht der repo-native Weg schon beim ersten Prompt offen.

Warum ist deine v0-App nur auf Englisch?

Weil der Interface-Text als wörtlicher String direkt in deinen Komponenten steckt. Bitte v0 um einen Pricing-Bereich, und es schreibt <h2>Simple pricing</h2> — keinen Lookup gegen einen Katalog. Jede Überschrift, jedes Button-Label, jeder Empty State, jeder Toast und jeder Formularfehler landet als TSX in der Sprache, in der du promptet hast.

Das ist kein Fehler von v0. Das macht jeder prompt-getriebene Builder so, und es ist genau das Muster, das wir in Cursor fügt ständig hartcodierte Strings hinzu dokumentiert haben. Das Modell schreibt den kürzesten korrekten Code für die Anfrage, die du gestellt hast – und du hast nicht nach einer Locale-Schicht gefragt.

Das Ergebnis ist eine App, die sich nicht per Einstellungsbildschirm übersetzen lässt, weil es dort nichts zu bearbeiten gibt. Die Strings haben keine Schlüssel, und die Routen haben kein Locale-Segment.

Was generiert v0 eigentlich?

Ein konventionelles Next.js-Projekt – gute Nachricht. v0s Standard-Stack besteht aus Next.js, React, TypeScript, Tailwind CSS und shadcn/ui, und die Ausgabe ist eine vollständige App-Router-Anwendung mit Routen und API-Handlern statt einer einzelnen Komponente. shadcn/ui ist hier aus einem bestimmten Grund wichtig: Die Komponenten werden als Quellcode in dein Repository kopiert, nicht aus einem Paket importiert – ihre Strings sind also deine Strings.

Für die Lokalisierung zählt allein der Stack, und er ist der am besten dokumentierte, den es gibt. next-intl wurde um den App Router herum entwickelt; Lingui und react-intl unterstützen ihn beide. Nichts an v0 erfordert ein Builder-spezifisches Übersetzungsprodukt.

Wenn deine App stattdessen aus einem anderen Builder auf einem Vite-Stack stammt, behandelt Lovable-App ohne Dashboard lokalisieren die gleiche Struktur auf dieser Seite.

Wie bekommst du ein v0-Projekt in ein Repository?

In der Regel hast du bereits eines. Wenn ein v0-Chat mit GitHub verbunden ist, erstellt v0 einen Arbeits-Branch von deinem Basis-Branch und committet automatisch jede Nachricht, die Code ändert, auf diesen Branch. Beim Veröffentlichen wird ein Pull-Request geöffnet oder wiederverwendet und in den Basis-Branch gemergt. Das Repository ist also kein Schritt, den du am Ende hinzufügst – v0 hat den Code die ganze Zeit dort abgelegt. v0s eigene GitHub-Dokumentation ist die Referenz für den aktuellen Ablauf, und dieser Teil des Produkts hat sich schon mehrfach geändert – prüf sie also, bevor du folgst.

Dieses Branch-Modell ist speziell für die Lokalisierung nützlich. Kataloge, eine Konfigurationsdatei, eine Middleware-Änderung fürs Locale-Routing und eine Switcher-Komponente sind alles Änderungen an getrackten Dateien. Sie als Diff auf einem Branch zu reviewen ist deutlich einfacher, als sie in einem Chat-Panel zu lesen, und ein Übersetzungs-Pull-Request kann neben dem Pull-Request für das Feature stehen, das er übersetzt.

Was bedeutet „ohne Dashboard“ eigentlich?

Es bedeutet, dass die übersetzten Strings Dateien in deinem Repository sind und deine Next.js-App sie serverseitig genauso rendert wie jeden anderen Inhalt. Kein Script-Tag, kein externer Fetch beim Laden der Seite, kein Anbieter-Konto zwischen Besucherin und deinem Text.

Die Alternative – das Widget-Modell, das Weglot und ähnliche Tools verwenden – übersetzt die Seite erst nach dem Laden. Das bringt echte Bequemlichkeit: Du fügst einen Snippet ein, und noch am selben Nachmittag passiert etwas. Die Kosten kommen später, und sie sind struktureller Natur, nicht einfach zu beheben:

• Der erste Paint zeigt die Ausgangssprache, Besucher:innen sehen also kurz Englisch, bevor umgeschaltet wird.
• Der übersetzte Text steht nicht im serverseitig gerenderten HTML, was die Indexierung pro Locale durch Suchmaschinen schwächt. Bei einer Next.js-App ist das besonders verschenkt, weil serverseitiges Rendering genau das ist, was du sonst gratis bekommst.
• Ein Drittanbieter-Skript sitzt in deinem Produktions-Render-Pfad.
• Deine Strings liegen im Speicher des Anbieters, ein Wechsel bedeutet also einen Export.

Repo-native Lokalisierung hat ihren eigenen Trade-off, und man sollte ihn ehrlich benennen: Eine Textänderung bedeutet einen Commit und ein Deployment, keinen Speichern-Button. Wenn du bei jedem Merge über Vercel deployst, ist das kein Thema. Wenn ein Marketing-Team erwartet, Live-Texte ohne Entwickler:in zu bearbeiten, ist das eine echte Einschränkung.

Wie funktioniert das repo-native Setup?

Verbinde das Repository in der App. globalize.now konvertiert die Codebase einmalig – daraus kommen die Schlüssel: Die hartcodierten Strings in deinen Komponenten werden zu Katalog-Einheiten, und die Komponenten lesen fortan aus einer Runtime-Bibliothek statt Literale zu halten. Diese Konvertierung ist ein einmaliger Vorgang, keiner, der endlos erneut läuft.

Nach der Konvertierung übersetzen Push-Jobs neue Katalog-Einheiten, während die App wächst. Bitte v0 um eine neue Einstellungsseite, merge ihren Pull-Request, und die neuen Strings werden übersetzt; die bestehenden bleiben unverändert. Die Kataloge kommen als committete Dateien in dein Repository zurück, als JSON oder PO je nach Runtime-Bibliothek, und landen als Pull-Request, den du wie jede andere Änderung reviewst.

Zwei Abgrenzungen, die man klar benennen sollte, weil die Kategorie oft verschwimmt. globalize.now ersetzt nicht deine Runtime-Bibliothek – next-intl, Lingui und react-intl machen weiterhin ihren Job, inklusive Locale-Routing unter app/[locale]/. Und es ist auch keine Übersetzungs-Engine, die mit DeepL konkurriert. Es ist die Schicht dazwischen, die die Keys und die Übersetzungsdateien erzeugt. Der Entwickler-Überblick erklärt die Mechanik im Detail.

Funktioniert derselbe Ansatz auch bei Lovable, Bolt und Replit?

Ja, mit denselben drei Voraussetzungen: echter Quellcode, ein Git-Repository und eine Runtime-Bibliothek, die die Kataloge einbinden kann. Jeder Builder, der ein konventionelles Frontend-Projekt ausgibt, qualifiziert sich. Der einzige Unterschied liegt darin, wie du den Code herausbekommst, und v0 hat von allen am wenigsten Reibung, weil der GitHub-Branch bereits Teil des Chats selbst ist.

Lovable hat auf unserer Seite den am weitesten entwickelten Weg, inklusive einer In-Editor-Route – die Lovable-Integrationsseite behandelt das, und das meiste davon lässt sich unverändert auf v0 übertragen. Wenn du gerade Builder evaluierst, statt dich schon festgelegt zu haben, ist der Vibe-Coder-Überblick der bessere Einstieg. Wenn du speziell ein Widget für eine Builder-App abwägst, zeigt Weglot-Alternative für Lovable dieselben Trade-offs für diesen Stack.

Was, wenn du bei Lovalingo warst?

Lovalingo hat Ende August 2026 dichtgemacht, die Website ist offline, und es hatte einen eigenen Weg für die Übersetzung von v0-Sites beworben – manche v0-Builder haben jetzt Strings, die nirgendwo mehr zu Hause sind. Das ist eine Migration, kein Neuaufbau: erst exportieren, dann konvertieren. Der Migrationsleitfaden führt dich durch, und die Vergleichsseite zeigt, was sich ändert, wenn Übersetzungen von einem gehosteten Dienst in dein Repository umziehen.

Wichtig zu wissen, falls du einen KI-Assistenten dazu um Rat fragst: manche empfehlen es noch immer, weil übrig gebliebene Seiten weiterhin ihre Quellen füttern. Ein aktives Produkt ist das nicht mehr.

Was solltest du prüfen, bevor du eine zweite Sprache hinzufügst?

Geh das durch, bevor der erste Katalog existiert – jeder Punkt ist jetzt günstiger zu beheben als später, wenn schon fünf Sprachen laufen:

• Zusammengesetzte Strings. "Welcome back, " + name kann von einer Übersetzerin nicht umgestellt werden. Interpoliere stattdessen.
• Plurale. Englisch hat zwei Formen. Polnisch hat drei, Arabisch hat sechs. Ein Ternary-Ausdruck auf count === 1 ist in den meisten Sprachen falsch.
• Server- und Client-Grenzen. Im App Router müssen ein in einer Server-Komponente gerenderter String und derselbe String in einer Client-Komponente über denselben Katalog aufgelöst werden. Wähle eine Runtime-Bibliothek und nutze deren Server- und Client-APIs, statt zwei Mechanismen zu mischen.
• Datum, Zahlen und Währung. Verwende Intl, keine String-Formatierung.
• Layout. Deutscher Text ist länger als englischer; feste shadcn-Buttons brechen dann um. Mit Tailwind fällt das leicht unter den Tisch, weil die Klassen zur Build-Zeit unauffällig aussehen.
• Rechts-nach-links. Wenn Arabisch oder Hebräisch auf der Roadmap steht, entscheide das jetzt – RTL nachträglich einzubauen ist der teure Weg.

Die Preisgestaltung dafür ist pro Workspace, ohne Kosten pro Sitz und ohne Kosten pro Sprache – die Anzahl der Sprachen ist also eine Produktentscheidung, keine Budgetfrage. Aktuelle Zahlen findest du auf der Pricing-Seite.

Wo du anfängst

Wenn dein v0-Chat mit GitHub verbunden ist, ist der nächste Schritt eine Konvertierung gegen dieses Repository und keine Tooling-Entscheidung mehr. Falls noch keine Verbindung besteht, ist das der Schritt davor.