Wie lokalisiert man eine Base44-App ohne Dashboard?

Du lokalisierst eine Base44-App, indem du sie über die von Base44 bereitgestellte bidirektionale Synchronisation mit GitHub verbindest und die Übersetzungskataloge als committete Dateien in diesem Repository hältst. Base44 spiegelt ohnehin jede Änderung zwischen Editor und Repository, sobald also Übersetzungsdateien auf dem main-Branch landen, sind sie Teil der App. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur: Sie erzeugt die Schlüssel und Übersetzungsdateien, und die Runtime-Bibliothek in deinem Projekt liefert sie aus. Kein Dashboard steht im Laufzeitpfad, und nichts übersetzt die Seite nachträglich beim Laden.

Warum ist deine Base44-App nur auf Englisch?

Weil die Interface-Texte als Literal-Strings direkt in deinen Komponenten stecken. Wenn du Base44 nach einer Buchungsseite fragst, schreibt es <h2>Your bookings</h2> in eine React-Komponente – keinen Lookup gegen einen Katalog. Jede Überschrift, jedes Button-Label, jeder Empty State, jeder Toast und jede Validierungsmeldung landet als JSX in der Sprache, in der du gepromptet hast.

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

Base44 zu bitten, „die App ins Deutsche zu übersetzen“, löst das Problem auch nicht. Du bekommst eine deutsche Kopie der Screens, die das Modell inspiziert hat, oder ein kleines Strings-Objekt, das es sich spontan ausdenkt. Der nächste Prompt schreibt wieder neuen Text auf Englisch, weil nichts im Projekt festlegt, dass Text durch einen Katalog laufen muss.

Was generiert Base44 eigentlich?

Ein Standard-React-Projekt, gebaut mit Vite. Base44s eigene Dokumentation zur Projektstruktur zeigt das Layout, das du im Code-Tab und in einem verbundenen Repository vorfindest: src/pages enthält eine Datei pro Route, Home.jsx wird also zu / und Settings.jsx zu /settings; src/components enthält die wiederverwendbaren Bausteine mit einem ui/-Ordner vorgefertigter Komponenten; src/api, src/hooks, src/lib und src/utils enthalten den SDK-Client, Hooks und Helper.

Zwei Verzeichnisse sind für die Lokalisierung wichtiger als die anderen. functions/ enthält deine Backend-Logik, eine TypeScript-Datei pro Funktion, und diese Dateien formatieren Text, den Nutzer:innen lesen: Fehlerantworten, E-Mails, generierte Dokumente. entities/ enthält dein Datenmodell als JSON-Schema-Dateien, und bei bidirektionaler Synchronisation werden die Entities in Base44 verwaltet, nicht im Repository.

Eine Base44-App hat also zwei String-Oberflächen, die Kataloge abdecken können – den React-Client und die Backend-Funktionen – und eine, die sie nicht abdecken können: die Daten innerhalb der Entities. Darauf kommen wir weiter unten zurück.

Wie bringst du eine Base44-App in ein Repository?

Base44 liefert die Verbindung direkt mit. Öffne im Editor das Dashboard, klick auf das GitHub-Symbol und stelle die Verbindung her. Du autorisierst die Base44-Builder-App für deinen GitHub-Account oder deine Organisation, wählst aus, auf welche Repositories sie zugreifen darf, und legst ein neues Repository für die App an. Ab diesem Moment bleiben Repository und Editor in beide Richtungen synchron.

Zwei Regeln aus der Base44-Dokumentation bestimmen alles Weitere. Erstens: Die Synchronisation läuft automatisch – Änderungen, die du in Base44 machst, einschließlich Änderungen, die die KI aus einem Prompt heraus macht, werden ohne Push-Schritt ins Repository committet; einen Button zum manuellen Push gibt es nicht. Zweitens: Der Weg zurück führt über den main-Branch. Alles, was in main gemergt wird, wird in der Base44-App sichtbar, master oder jeder andere Default-Branch-Name wird nicht unterstützt. Nach einem Merge klickst du auf Publish, um die neue Version für Nutzer:innen live zu schalten.

Die bidirektionale Synchronisation setzt den Builder-Plan oder höher voraus, und nur die Besitzerin der App kann die erste Verbindung herstellen. Falls dein Account die ältere einseitige „Export to GitHub“-Integration eingerichtet hat, findest du im GitHub-Panel einen Link, um sie zu trennen und mit der bidirektionalen Synchronisation neu zu verbinden – der einseitige Weg bringt nie etwas zurück in den Editor, genau die Richtung, die Lokalisierung braucht.

Für lokale Arbeit: Repository klonen, npm install ausführen, die Base44-CLI installieren, dann base44 login und base44 link, um den Klon mit seiner App zu verknüpfen. base44 dev führt das Frontend gegen ein lokales Backend aus. Das Mergen deines lokalen Branches nach main synchronisiert es zurück.

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

Es bedeutet, dass die übersetzten Strings nie in einem gehosteten Dienst liegen, den deine App aufrufen oder aus dem du exportieren musst. Sie liegen in src/locales/de.json neben src/pages/Home.jsx, versioniert in denselben Commits, geprüft in denselben Pull Requests und mit demselben Publish-Klick deployt.

Die alternativen Ansätze kosten bei Base44 speziell etwas. Ein Runtime-Widget, das die Seite im Browser übersetzt, lässt den Quellcode unangetastet – im Repository steht die App also weiterhin auf Englisch, und jede Besucherin zahlt beim Laden mit der Übersetzungsverzögerung. Ein gehostetes Übersetzungstool mit eigenem Editor hält die Wahrheit außerhalb des Repositorys – die von Base44 gebaute bidirektionale Synchronisation synchronisiert dann eine Codebase, die die Sprachen gar nicht enthält. Beide Ansätze schieben ein zweites System zwischen dich und Text, der bereits in Dateien liegt, die dir gehören.

Der repo-native Ansatz nutzt die Synchronisation genau so, wie sie gedacht ist. Kataloge sind Dateien. Dateien werden committet. Committete Dateien erreichen main. main erreicht den Editor. Das ist die gesamte Pipeline, und nichts davon ist lokalisierungsspezifisch.

Wie funktioniert das repo-native Setup?

Verbinde das Repository in der App und führe die Konvertierung einmal aus. Die Konvertierung findet die Literal-Strings in deinen Komponenten und Backend-Funktionen, versieht sie mit Schlüsseln, bindet bei Bedarf eine Runtime-Bibliothek wie i18next oder Lingui ein, falls das Projekt noch keine hat, und öffnet einen Pull Request gegen dein Repository mit dem Quellkatalog und den ersten Zielsprachen. Dieser Pull Request ist die gesamte Übergabe. Prüfe ihn auf GitHub wie jede andere Änderung, merge ihn nach main, und Base44 spiegelt ihn in den Editor.

Von da an übersetzen Push-Jobs neue Katalogeinheiten. Wenn du Base44 nach einem neuen Feature fragst und die Synchronisation es committet, werden alle neuen Schlüssel im Quellkatalog übersetzt und als Pull Request geliefert. Mergen, auf Publish klicken, und das Feature ist in jeder Sprache live. An deinen Prompting-Gewohnheiten muss sich nichts ändern, und nichts in deiner App ruft zur Laufzeit einen externen Dienst auf.

Derselbe Ansatz läuft bei Lovable, Bolt, v0 und Replit, und die Mechanik ist identisch, weil alle vier dir ein konventionelles Frontend-Projekt an die Hand geben. Die Lovable-Anleitung geht am detailliertesten auf die Katalogstruktur ein, der Bolt-Guide behandelt den Export-Schritt für einen Builder ohne native Synchronisation, und der Vite-Guide für Lovables klassischen Stack passt auf Code-Ebene am ehesten zu Base44s React- und Vite-Output. Wenn du Builder vergleichst statt dich bereits festgelegt zu haben, ist die Vibe-Coder-Übersicht der bessere Einstiegspunkt.

Welche Strings stecken in den Backend-Funktionen?

Alles, was eine Nutzerin liest und serverseitig erzeugt wird. Ein Validierungsfehler, den eine Funktion zurückgibt, die Betreffzeile einer versendeten E-Mail, der Inhalt eines generierten PDFs, der Text einer Benachrichtigung. Diese Strings tauchen nie als JSX auf, ein Frontend-Katalog enthält sie also nicht, und ein Runtime-Widget kann sie nicht sehen.

Das Muster ist dasselbe wie beim Client. Lies die angeforderte Locale aus dem eingehenden Request, lade auf Funktionsseite den passenden Katalog dafür und teile den Schlüssel-Namensraum mit dem Client, damit eine Nachricht in der Oberfläche und in einer API-Antwort dasselbe bedeutet. Da das functions/-Verzeichnis im Repository liegt, behandelt die Konvertierung diese Dateien wie jede andere Quelle, und die Kataloge liegen direkt daneben.

Was ist mit den Inhalten innerhalb der Entities?

Das ist die Base44-spezifische Grenze. Entities sind dein Datenmodell, verwaltet innerhalb von Base44, und bei bidirektionaler Synchronisation sind sie kein Teil des Repositorys. Ein Datensatz wie ein Produktname, eine Leistungsbeschreibung oder ein Hilfeartikel ist Dateninhalt, kein Interface-Text, und kein Katalog wird ihn je enthalten.

Dateninhalte brauchen eine Sprachdimension direkt an der Entity: ein Locale-Feld oder ein Feld pro Sprache, plus Queries, die die Locale der Besucherin auslesen. Das Setup entspricht dem, das wir für Datenbankinhalte in Lovable-Apps beschreiben, und es ist eine Datenmodell-Entscheidung, die du im Base44-Entity-Editor triffst, keine Entscheidung des Lokalisierungstools. Plane das früh, denn ein Sprachfeld nachträglich in eine Entity mit bestehenden Datensätzen einzubauen ist deutlich aufwendiger als es gleich in eine neue einzubauen.

Was, wenn du bei Lovalingo warst?

Lovalingo hat Ende August 2026 den Betrieb eingestellt, und zu den veröffentlichten Anwendungsfällen zählte Base44 neben Lovable, v0 und Bolt. Wer eine Base44-App darüber lokalisiert hat, braucht jetzt einen neuen Ort für diese Strings. Das ist eine Migration, kein Neuaufbau: erst exportieren, dann konvertieren. Der Migrationsguide führt durch den Prozess, und die Vergleichsseite zeigt, was sich ändert, wenn Übersetzungen von einem gehosteten Dienst in dein Repository umziehen.

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

Prüfe, dass die Synchronisation bidirektional läuft und nicht die alte Export-Variante. Öffne das GitHub-Panel in Base44 und kontrolliere, ob ein verbundenes Repository gemeldet wird; falls dort der Link „Suchst du das alte Setup?“ auftaucht, bist du auf dem einseitigen Weg und musst neu verbinden.

Prüfe, dass dein Default-Branch main heißt. Base44 spiegelt nur diesen Branch zurück – ein Pull Request, der woanders gemergt wird, erreicht den Editor nie.

Halte Ausschau nach einer Runtime-Bibliothek. Falls du Base44 irgendwann nach Sprachen gefragt hast, wurde vielleicht i18next oder ein selbstgebauter Context hinzugefügt; die Konvertierung übernimmt, was vorhanden ist, und speist es.

Entscheide, wo Entity-Inhalte ihr Sprachfeld bekommen, bevor du Datensätze in einer zweiten Sprache anlegst. Diesen Teil übernehmen die Kataloge nicht für dich.

Prüfe dein Routing. Base44-Seiten sind dateibasiert, ein Locale-Präfix in der URL ist also eine einmalige Routing-Entscheidung, die bestimmt, wie Suchmaschinen jede Sprache sehen. Der Guide zu Sprachumschalter und hreflang behandelt die Optionen, und sie lassen sich direkt übertragen.

Wo du anfängst

Aktiviere die bidirektionale GitHub-Synchronisation in Base44, falls noch nicht geschehen, prüfe, dass der Branch main heißt, und verbinde das Repository in der App. Der erste Pull Request konvertiert die Codebase. Alles danach ist ein Merge, ein Publish-Klick und die Sprachen, um die du gebeten hast. Die Lovable-Integrationsseite beschreibt denselben Ablauf für einen Builder mit In-Editor-Route, und das meiste davon lässt sich unverändert auf Base44 übertragen.