Wie machst du eine Replit-App mehrsprachig — ohne Dashboard?

Du machst eine Replit-App mehrsprachig, indem du ihr Git-Repository mit GitHub verbindest und die Übersetzungs-Kataloge als committete Dateien in diesem Repository hältst. Replit speichert bereits jeden Checkpoint des Agents als Git-Commit, sodass das Repository existiert, bevor du überhaupt an Sprachen denkst; die Arbeit besteht darin, es auf GitHub zu bringen und die Kataloge über dieselbe Historie zurückkommen zu lassen. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur: Sie erzeugt die Schlüssel und Locale-Dateien, und die Runtime-Bibliothek, die deine App bereits nutzt, liefert sie aus. Kein Dashboard sitzt im Laufzeitpfad, und nichts übersetzt die Seite, nachdem sie geladen wurde.

Warum funktioniert es nicht, den Agent zu bitten, die App zu übersetzen?

Weil es nichts gibt, in das übersetzt werden könnte. Wenn du Replit Agent nach einem Dashboard promptest, schreibt er <h2>Your bookings</h2> in eine Komponente — kein Lookup gegen einen Katalog. Jede Überschrift, jeder Button, jeder Empty State, jeder Toast und jeder Validierungsfehler landet als Literal in JSX, in der Sprache des Prompts.

Bittest du den Agent später, „die App ins Afrikaans zu übersetzen“, bekommst du eines von zwei Halb-Ergebnissen: eine zweite Kopie der Komponenten mit ausgetauschtem Text, oder ein handgestricktes translations-Objekt, das die Screens abdeckt, die der Agent sich gerade angesehen hat. Keines von beiden ist eine Locale-Schicht. Das nächste Feature liefert wieder auf Englisch aus. Wir haben dasselbe wiederkehrende Muster in Cursor fügt weiterhin hartcodierte Strings hinzu dokumentiert; Replit Agent verhält sich nicht anders, weil er den Prompt vor sich löst, nicht die Architektur dahinter.

Die Lösung ist strukturell: Gib den Strings Schlüssel, lege die Übersetzungen in Dateien ab, und lass die Runtime aus diesen Dateien lesen. Das ist es, was „mehrsprachig“ in einer Codebase bedeutet, und es ist eine einmalige Änderung.

Was generiert Replit Agent tatsächlich?

Ein konventionelles Web-Projekt — das ist die gute Nachricht. Replits kuratierte App-Typen bauen im Frontend auf React mit ShadCN UI, typischerweise gepaart mit einem Express-Server im selben Projekt, alles in TypeScript. Seit September 2025 arbeitet der Agent auch mit jedem Framework, das du mitbringst, inklusive importierter GitHub-Repositories — ein Next.js- oder Vue-Projekt ist also möglich; der Standardweg bleibt aber der React-Stack.

Für die Lokalisierung ist der Stack die einzige Tatsache, die zählt, und er ist solider Boden. React plus Vite plus TypeScript ist die am besten unterstützte Kombination im i18n-Ökosystem: i18next, Lingui und react-intl zielen alle direkt darauf ab. Hat der Agent stattdessen eine Next.js-App gebaut, stellt sich die Wahl zwischen next-intl, react-i18next und Lingui — dieser Vergleich ist ein eigener Beitrag.

Was sich von einem Frontend-only-Builder unterscheidet, ist die zweite Hälfte des Projekts. Eine Replit-App hat meist einen Server, und Server haben auch Strings. Mehr dazu weiter unten.

Wo liegt das Git-Repository in einer Replit-App?

Es ist bereits da. Replits Versionskontrolle basiert unter der Haube auf Git, und Checkpoints des Agents sind Commits in diesem Repository. Jedes Mal, wenn der Agent ein Feature fertigstellt und dir einen Rollback-Punkt anbietet, hat er committet. Replits eigene Dokumentation empfiehlt, für langfristiges Tracking auf gewöhnliche Git-Commits umzusteigen, wenn du mit externen Repositories arbeitest — exakt die Situation hier.

So bringst du es auf GitHub:

1. Füge das Git-Tool aus dem Bereich Tools des Projekt-Editors hinzu.
2. Verbinde dein GitHub-Konto unter Connected Services und verbinde dann das Repository über das Git-Panel. Wurde das Projekt noch nie initialisiert, bietet das Panel an, das zuerst zu erledigen.
3. Push. Das Panel pusht mit einem Klick und bleibt mit allem synchron, was du in der Shell ausführst — also funktioniert auch git push origin main.

Replit unterstützt außerdem GitLab und Bitbucket, und derselbe Ablauf gilt dort ebenso. Der Anbieter ist nicht der Punkt; der Punkt ist, dass das Repository jetzt irgendwo liegt, wo ein Lokalisierungs-Job einen Pull Request dagegen öffnen kann.

Erledige das, bevor du auch nur einen einzigen String berührst. Lokalisierungsarbeit ist Datei-Arbeit, und ein Diff ist der richtige Ort, um sie zu prüfen.

Was bedeutet „ohne Dashboard“ für eine Replit-App?

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

Die Alternative ist ein Laufzeit-Widget, das Text austauscht, nachdem die Seite gerendert wurde. Seine Kosten sind struktureller Natur: Der erste Paint ist Englisch, der übersetzte Text steht nicht im HTML, das Crawler zuerst lesen, ein Drittanbieter-Script sitzt in deinem Produktionspfad, und deine Strings leben im Speicher des Anbieters — ein Wechsel bedeutet also einen Export. Die Lovable-Version dieses Arguments findest du in Lokalisierung einer Lovable-App ohne Dashboard, und sie überträgt sich unverändert auf Replit.

Es gibt einen Replit-spezifischen Grund, warum das hier noch mehr zählt. Replit deployt die App für dich, sodass die laufende Kopie auf deiner Replit-Domain genau das ist, was zum Deploy-Zeitpunkt im Projekt steckt. Ein Widget würde dieses Deployment von außen übersetzen. Kataloge im Repository bedeuten, dass das Deployment bereits jede Sprache enthält, und die Replit-Vorschau zeigt dir die deutsche Version, bevor du sie live schaltest.

Der Trade-off ist real und sollte klar benannt werden: Eine Textänderung bedeutet einen Commit und ein Redeploy, keinen Speichern-Button. Für jemanden, der solo aus Replit heraus released, ist das kein Problem; für jemanden, der erwartet, Live-Text zu bearbeiten, ohne das Projekt anzufassen, ist es eine Einschränkung.

Wie funktioniert das repo-native Setup?

Verbinde das Repository in der globalize.now-App. Die Konvertierung läuft einmalig gegen die Codebase: Hartcodierte Strings werden zu Katalogeinheiten mit Schlüsseln, und die Komponenten lesen fortan aus einer Runtime-Bibliothek statt Literale zu enthalten. Das ist ein einmaliger Vorgang, kein wiederkehrender.

Nach der Konvertierung übersetzen Push-Jobs neue Katalogeinheiten, sobald die App wächst. Bitte den Agent um eine neue Einstellungsseite, pushe, und die neuen Einheiten werden übersetzt; die bestehenden bleiben unverändert. Kataloge kommen als committete Dateien zurück, JSON oder PO je nach Runtime-Bibliothek, in einem Pull Request, den du wie jede andere Änderung prüfst.

Zwei Abgrenzungen, weil die Kategorie unscharf ist. globalize.now ersetzt nicht die Runtime-Bibliothek; i18next, Lingui und next-intl erledigen weiterhin ihre Aufgabe. Und es ist keine Übersetzungs-Engine, die mit DeepL konkurriert. Es ist die Schicht dazwischen, die die Schlüssel und Übersetzungsdateien erzeugt. Die Entwicklerübersicht erklärt die Mechanik.

Wie kommen die Übersetzungen zurück in Replit?

Über dasselbe Git-Panel, nur in die andere Richtung. Das ist der Schritt, der sich von Bolt oder Lovable unterscheidet, weil Replit auch der Ort ist, an dem die App läuft.

1. Prüfe und merge den Pull Request auf GitHub.
2. Wähle im Replit-Git-Panel Pull. Wenn du oder der Agent in der Zwischenzeit dieselben Dateien geändert habt, markiert das Panel die Konflikte, und du löst sie im Editor, bevor du den Merge abschließt.
3. Deploye neu. Die Kataloge sind jetzt Teil des Projekts, also enthält das Deployment jede Sprache.

Ein Vorbehalt, der spezifisch für Replit ist: Agent-Checkpoints stellen den gesamten Projektstatus wieder her, inklusive Dateien. Setzt du auf einen Checkpoint zurück, der vor dem Pull des Übersetzungs-Branches erstellt wurde, verschwinden die Kataloge mit. Behandle den Merge als Meilenstein, lass den Agent danach einen Checkpoint erstellen und setze auf diesen zurück statt auf einen früheren.

Welche Strings liegen auf dem Server?

Die, die das Frontend nie als JSX zu Gesicht bekommt. Eine Replit-App mit einem Express-Backend hat eine zweite String-Ebene: API-Fehlermeldungen, Validierungsantworten, E-Mail-Betreffs, Benachrichtigungstexte, CSV-Header — alles, was der Server formatiert, bevor er es sendet. Ein Frontend-Katalog erreicht sie nicht, und ein Widget sieht sie überhaupt nicht, weil sie nie im DOM stehen.

Das Muster ist dasselbe wie beim Client, nur serverseitig angewendet. Gib dem Server eine Kopie der Runtime-Bibliothek, lies das Locale der Besucherin aus dem Request (ein Accept-Language-Header oder ein Locale-Feld im Nutzerdatensatz) und formatiere Antworten aus dem Katalog statt aus String-Literalen. Der Schlüssel-Namespace bleibt geteilt, sodass errors.booking.overlap in einem Toast dasselbe bedeutet wie in einer 409-Antwort.

Lässt man das aus, wirkt die App mehrsprachig — bis zum ersten Fehler, dann spricht sie Englisch.

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

Geh das vor der Konvertierung durch, denn jeder Punkt ist jetzt günstiger zu beheben als nachdem fünf Sprachen live sind:

• Zusammengesetzte Strings. "Welcome back, " + user.name kann von einer Übersetzerin nicht umgestellt werden. Interpoliere stattdessen.
• Pluralformen. Englisch hat zwei Formen, Polnisch drei, Arabisch sechs. Ein Ternary auf count === 1 ist in den meisten Sprachen falsch.
• Datum, Zahlen und Währung. Verwende Intl, nicht String-Formatierung, sowohl auf Client- als auch auf Server-Seite.
• Layout. Deutsch und Finnisch sind länger als Englisch. Buttons mit fester Breite brechen, und Tailwind-Klassen sehen so lange gut aus, bis der Text tatsächlich ankommt.
• Rechts-nach-links (RTL). Steht Arabisch oder Hebräisch auf der Roadmap, entscheide jetzt. RTL nachträglich einzubauen ist der teure Weg.
• Katalog-Drift. Sobald Kataloge existieren, ist ein Schlüssel, der in einem Locale hinzugefügt wird und in den anderen fehlt, ein stiller Bug. Warum Übersetzungsdateien auseinanderlaufen erklärt, wie das passiert und was ein Push-Job dagegen tut.

Die Preisgestaltung erfolgt pro Workspace, ohne Kosten pro Nutzer oder pro Sprache — die Anzahl der Sprachen ist damit eine Produktentscheidung und keine Budgetfrage. Aktuelle Zahlen findest du auf der Preise-Seite. Für dieselbe Anleitung mit anderen Buildern ist die Übersicht für Vibe Coder der Einstiegspunkt.

Wo du anfängst

Ist dein Replit-Projekt bereits mit GitHub verbunden, ist der nächste Schritt eine Konvertierung gegen dieses Repository — keine Tooling-Entscheidung. Ist es noch nicht verbunden, ist das Git-Panel der Schritt davor.