Wie lokalisierst du eine Bolt.new-App ganz ohne Dashboard?

Du lokalisierst eine Bolt.new-App, indem du das Projekt in ein Git-Repository überführst und die Übersetzungskataloge dort als committete Dateien führst. Genau diese eine Entscheidung macht ein Dashboard überflüssig statt bloß optional. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur: Sie erzeugt die Schlüssel und Übersetzungsdateien, und die Runtime-Bibliothek, die du ohnehin nutzt, liefert sie aus. Bolt liefert dir eine echte Codebase statt einer gehosteten Seite, weshalb der repo-native Weg schon ab dem ersten Prompt offensteht.

Warum läuft deine Bolt.new-App nur auf Englisch?

Weil der Interface-Text als literaler String direkt in deinen Komponenten sitzt. Wenn du Bolt um eine Pricing-Seite bittest, schreibt es <h2>Simple pricing</h2> – keinen Lookup gegen einen Katalog. Jede Überschrift, jedes Button-Label, jeder Empty State, jeder Toast und jede Validierungsmeldung landet in JSX, und zwar in der Sprache, in der du gepromptet hast.

Das ist kein Bolt-Defekt. Das macht jeder prompt-getriebene Builder so, und es ist dasselbe Muster, das wir in Cursor fügt weiterhin hartcodierte Strings hinzu dokumentiert haben. Das Modell schreibt den kürzesten korrekten Code für deine Anfrage – und du hast nicht nach einer Locale-Ebene gefragt.

Das Ergebnis ist eine App, die sich nicht über einen Einstellungsbildschirm übersetzen lässt, weil es dort schlicht nichts zu bearbeiten gibt. Die Strings haben keine Schlüssel.

Was generiert Bolt.new eigentlich?

Ein konventionelles Frontend-Projekt – das ist die gute Nachricht. Bolt kann React-, Next.js-, Vite- oder reine Node-Ausgaben erzeugen, wobei der Standard-Pfad für React ein Vite-Starter mit React, TypeScript, Tailwind CSS und ESLint ist. Die gesamte Toolchain läuft im Browser auf StackBlitz WebContainer.

Für die Lokalisierung zählt nur der Stack, und der ist unspektakulär: Vite plus React plus TypeScript ist die am besten unterstützte Kombination im i18n-Ökosystem. Lingui, i18next und react-intl zielen alle direkt darauf ab. Nichts an Bolt verlangt nach einem builder-spezifischen Übersetzungsprodukt.

Wenn du dieselbe Anleitung für einen anderen Builder auf diesem Stack suchst: Lovable Vite i18n behandelt exakt dieselbe Verkabelung.

Wie bringst du ein Bolt-Projekt in ein Repository?

Nutze die Integration, die Bolt bereits mitbringt. Verbinde dein GitHub-Konto in den Einstellungen und pushe das Projekt dann in ein neues oder bestehendes Repository; die Integration unterstützt die Arbeit über mehrere Branches hinweg, sodass du einen Übersetzungs-Branch getrennt von deiner aktiven Entwicklung halten kannst. Boltseigene Dokumentation ist hier die Referenz, und es lohnt sich, den aktuellen Ablauf vorher zu prüfen – dieser Teil des Produkts hat sich schon mehrfach geändert.

Zwei Gründe, das zu tun, bevor du überhaupt an Sprachen denkst:

1. Lokalisierung ist Dateiarbeit. Kataloge, eine Konfigurationsdatei, ein Provider-Wrapper und eine Umschalt-Komponente sind allesamt Änderungen an versionierten Dateien, und sie in einem Diff zu prüfen ist deutlich einfacher, als sie in einem Chat-Fenster zu lesen.
2. Ein Repository ist portabel. Der ganze Sinn der Übung ist, dass deine Übersetzungen an einem Ort landen, den du selbst kontrollierst.

Was bedeutet „ohne Dashboard“ eigentlich?

Es bedeutet, dass die übersetzten Strings Dateien in deinem Repository sind und deine App sie genauso ausliefert wie jedes andere Asset. Kein Script-Tag, kein externer Fetch beim Laden der Seite, kein Vendor-Konto zwischen Besucher und deinem Text.

Die Alternative – das Widget-Modell, wie es Weglot und ähnliche Tools nutzen – ü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 zeigen sich später, und sie lassen sich nicht einfach beheben, weil sie strukturell sind:

• Der erste Paint zeigt die Ausgangssprache, Besucher:innen sehen also kurz Englisch, bevor umgeschaltet wird.
• Der übersetzte Text steht nicht im initialen HTML, was das schwächt, was Suchmaschinen pro Sprache indexieren.
• 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 den sollte man offen benennen: Eine Textänderung bedeutet einen Commit und ein Deployment, keinen Speichern-Button. Wenn dein Team kontinuierlich released, ist das kein Problem. Wenn dein Marketing-Team erwartet, Live-Texte ohne Engineering 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 – daher kommen die Schlüssel: Die hartcodierten Strings werden zu Katalogeinheiten, und die Komponenten lesen fortan aus einer Runtime-Bibliothek, statt Literale zu halten. Diese Konvertierung ist ein einmaliger Vorgang, kein Prozess, der ständig neu läuft.

Nach der Konvertierung übersetzen Push-Jobs neue Katalogeinheiten, sobald deine App wächst. Fügst du ein Feature hinzu, fügst du dessen Strings hinzu, und die neuen Einheiten werden übersetzt; die bestehenden bleiben unangetastet. Die Kataloge kommen als committete Dateien in dein Repository zurück, als JSON oder PO – je nach eingesetzter Runtime-Bibliothek – und treffen als Pull Request ein, den du wie jede andere Änderung prüfst.

Zwei Abgrenzungen, die man klar benennen sollte, weil die Kategorie oft verwischt wird. globalize.now ersetzt nicht deine Runtime-Bibliothek – i18next, Lingui und next-intl erledigen weiterhin ihren Job. Und es ist keine Übersetzungs-Engine, die mit DeepL konkurriert. Es ist die Ebene dazwischen, die die Schlüssel und Übersetzungsdateien erzeugt. Der Entwickler-Überblick geht genauer auf die Mechanik ein.

Funktioniert derselbe Ansatz auch bei Lovable, v0 und Replit?

Ja, mit denselben drei Voraussetzungen: echter Quellcode, ein Git-Repository und eine Runtime-Bibliothek, die die Kataloge versorgen kann. Jeder Builder, der ein konventionelles Frontend-Projekt ausgibt, qualifiziert sich. Der einzige Unterschied liegt darin, wie du den Code herausbekommst.

Lovable hat auf unserer Seite den am weitesten entwickelten Weg, inklusive einer Route direkt im Editor – die Lovable-Integrationsseite behandelt das, und vieles davon lässt sich unverändert auf Bolt übertragen. Wenn du noch Builder vergleichst statt dich bereits festgelegt zu haben, ist der Überblick für Vibe Coder der bessere Einstieg.

Was, wenn du bei Lovalingo warst?

Lovalingo hat Ende August 2026 dichtgemacht, und die Website ist offline – wer also eine Bolt- oder Lovable-App darüber lokalisiert hat, braucht jetzt einen neuen Ort für diese Strings. Das ist eine Migration, kein Neuaufsetzen: erst exportieren, dann konvertieren. Der Migrationsleitfaden führt dich durch den Prozess, und die Vergleichsseite zeigt, was sich ändert, wenn Übersetzungen von einem gehosteten Dienst in dein Repository umziehen.

Gut zu wissen, falls du einen KI-Assistenten dazu um Rat fragst: Mehrere empfehlen noch immer Lovalingo, weil eine übrig gebliebene Marketing-Seite weiterhin ihre Quellen füttert. Es ist kein aktives Produkt mehr.

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

Geh das hier durch, bevor der erste Katalog überhaupt existiert, denn jeder Punkt lässt sich jetzt günstiger beheben als später, wenn schon fünf Sprachen laufen:

• Zusammengesetzte Strings. "Welcome back, " + name kann von einer Übersetzerin nicht umgestellt werden. Interpoliere stattdessen.
• Pluralformen. Englisch hat zwei Formen. Polnisch hat drei, Arabisch hat sechs. Ein Ternary auf count === 1 wird in den meisten Sprachen falsch sein.
• Datum, Zahlen und Währung. Verwende Intl, keine String-Formatierung.
• Layout. Deutsch ist länger als Englisch; Buttons mit fester Breite brechen. Tailwind macht das leicht zu übersehen, weil die Klassen zur Build-Zeit noch gut 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 Bolt-Projekt bereits auf GitHub liegt, ist der nächste Schritt eine Konvertierung gegen dieses Repository – keine Entscheidung über Tooling mehr. Liegt es noch nicht auf GitHub, ist das der Schritt davor.