How do you localize a Base44 app without a dashboard?

You localize a Base44 app by connecting it to GitHub with the two-way sync Base44 provides and keeping the translation catalogs in that repository as committed files. Base44 already mirrors every change between the editor and the repository, so the moment locale files land on the main branch they are part of the app. globalize.now is AI-powered localization infrastructure: it produces the keys and locale files, and the runtime library in your project serves them. No dashboard sits in the runtime path, and nothing translates the page after it loads.

Why is your Base44 app English-only?

Because the interface text is sitting inside your components as literal strings. When you prompt Base44 for a bookings page, it writes <h2>Your bookings</h2> into a React component, not a lookup against a catalog. Every heading, button label, empty state, toast and validation message lands in JSX in the language you prompted in.

That is not a Base44 defect. It is what every prompt-driven builder does, and it is the same pattern we documented in Cursor keeps adding hardcoded strings. The model writes the shortest correct code for the request you made, and you did not ask for a locale layer.

Asking Base44 to "translate the app to German" does not fix it either. You get a German copy of the screens the model inspected, or a small strings object it invents on the spot. The next prompt writes new text in English again, because nothing in the project says text has to go through a catalog.

What does Base44 actually generate?

A standard React project built with Vite. Base44's own project-structure docs show the layout you get in the Code tab and in a connected repository: src/pages holds one file per route, so Home.jsx becomes / and Settings.jsx becomes /settings; src/components holds the reusable pieces with a ui/ folder of pre-built components; src/api, src/hooks, src/lib and src/utils hold the SDK client, hooks and helpers.

Two directories matter more than the rest for localization. functions/ holds your backend logic, one TypeScript file per function, and those files format text users read: error responses, emails, generated documents. entities/ holds your data model as JSON schema files, and under two-way sync the entities are managed in Base44 rather than in the repository.

So a Base44 app has two string surfaces the catalogs can cover, the React client and the backend functions, and one they cannot, the data inside entities. That last one comes up again below.

How do you get a Base44 app into a repository?

Base44 ships the connection. In the editor, open the Dashboard, click the GitHub icon, and connect. You authorize the Base44 Builder app on your GitHub account or organization, pick which repositories it may access, and create a new repository for the app. From then on the repository and the editor stay aligned in both directions.

Two rules from Base44's docs shape everything that follows. First, sync is automatic: changes you make in Base44, including changes the AI makes from a prompt, are committed to the repository without a push step, and there is no button to push manually. Second, the way back is the main branch. Anything merged to main becomes visible in the Base44 app, and master or any other default branch name is not supported. After a merge you click Publish to make the new version live for users.

Two-way sync requires the Builder plan or higher, and only the app owner can make the initial connection. If your account set up the older one-way Export to GitHub integration, the GitHub panel has a link to disconnect it and reconnect with two-way sync; the one-way path never brings anything back into the editor, which is exactly the direction localization needs.

For local work, clone the repository, run npm install, install the Base44 CLI, then base44 login and base44 link to point the clone at its app. base44 dev runs the frontend against a local backend. Merging your local branch to main is what syncs it back.

What does "without a dashboard" mean for a Base44 app?

It means the translated strings never live in a hosted service that your app has to call or that you have to export from. They live in src/locales/de.json next to src/pages/Home.jsx, versioned in the same commits, reviewed in the same pull requests, and deployed by the same Publish click.

The alternative shapes each cost something on Base44 specifically. A runtime widget that translates the page in the browser leaves the source untouched, so the repository still says the app is English, and every visitor pays the translation delay on load. A hosted translation tool with its own editor holds the truth outside the repository, so the two-way sync that Base44 built is syncing a codebase that does not contain the languages. Both put a second system between you and text that already lives in files you own.

The repo-native shape uses the sync as it was designed. Catalogs are files. Files are committed. Committed files reach main. main reaches the editor. That is the whole pipeline, and none of it is specific to localization.

How does the repo-native setup work?

Connect the repository in the app and run the conversion once. The conversion finds the literal strings in your components and backend functions, gives them keys, wires a runtime library such as i18next or Lingui if the project does not have one, and opens a pull request against your repository with the source catalog and the first target languages. That pull request is the whole handover. Review it on GitHub as you would any other change, merge it to main, and Base44 mirrors it into the editor.

From there, push jobs translate new catalog units. When you prompt Base44 for a new feature and the sync commits it, any new keys in the source catalog get translated and delivered as a pull request. Merge it, click Publish, and the feature is live in every language. Nothing about your prompting habits has to change, and nothing in your app calls an external service at runtime.

The same approach is running on Lovable, Bolt, v0 and Replit, and the mechanics are identical because all four hand you a conventional front-end project. The Lovable walkthrough has the most detail on catalog structure, the Bolt guide covers the export step for a builder without native sync, and the Vite guide for Lovable's classic stack is the closest match for Base44's React and Vite output at the code level. If you are comparing builders rather than committed to one, the vibe coders overview is the better starting point.

Which strings live in the backend functions?

Anything a user reads that is produced server-side. A validation error returned from a function, the subject line of an email it sends, the body of a PDF it generates, the text of a notification. Those strings never appear as JSX, so a front-end catalog does not contain them and a runtime widget cannot see them.

The pattern is the same as on the client. Read the requested locale from the incoming request, load the catalog for that locale on the function side, and share the key namespace with the client so a message means the same thing in the UI and in an API response. Because the functions/ directory is in the repository, the conversion treats those files like any other source and the catalogs sit beside them.

What about the content inside entities?

This is the Base44-specific boundary. Entities are your data model, managed inside Base44, and under two-way sync they are not part of the repository. A record like a product name, a service description or a help article is data, not interface text, and no catalog will ever contain it.

Data content needs a language dimension on the entity itself: a locale field, or one field per language, and queries that read the visitor's locale. The setup is the same one we describe for database content in Lovable apps, and it is a data-model decision you make in the Base44 entity editor, not a localization-tool decision. Plan it early, because retrofitting a language field onto an entity with existing records is more work than adding it to a new one.

What if you were on Lovalingo?

Lovalingo shut down at the end of August 2026, and its published use cases had included Base44 alongside Lovable, v0 and Bolt. Anyone who localized a Base44 app through it needs somewhere for those strings to land. That is a migration rather than a fresh setup: export first, then convert. The migration guide walks through it, and the comparison page covers what changes when translations move from a hosted service into your repository.

What should you check before adding a second language?

Confirm the sync is two-way, not the legacy export. Open the GitHub panel in Base44 and check that it reports a connected repository; if it offers the "Looking for the old setup?" link, you are on the one-way path and need to reconnect.

Confirm your default branch is main. Base44 only mirrors that branch back, so a pull request merged anywhere else never reaches the editor.

Look for a runtime library. If you asked Base44 for languages at any point, it may have added i18next or a hand-rolled context; the conversion keeps what is there and feeds it.

Decide where entity content will get its language field before you add records in a second language. The catalogs will not do this part for you.

Check your routing. Base44 pages are file-based, so a locale prefix in the URL is a routing decision you make once, and it decides how search engines see each language. The language switcher and hreflang guide covers the choices and they transfer directly.

Where to start

Turn on two-way GitHub sync in Base44 if it is not already on, confirm the branch is main, and connect the repository in the app. The first pull request converts the codebase. Everything after that is a merge, a Publish click, and the languages you asked for. The Lovable integration page describes the same flow for a builder with an in-editor route, and most of what is written there transfers to Base44 unchanged.