How do you localize a Bolt.new app without a dashboard?

You localize a Bolt.new app by moving the project into a Git repository and keeping the translation catalogs there as committed files. That single decision is what makes a dashboard unnecessary rather than merely optional. globalize.now is AI-powered localization infrastructure: it produces the keys and locale files, and whatever runtime library you already use serves them. Bolt hands you a real codebase rather than a hosted page, so the repo-native route is open from the first prompt.

Why is your Bolt.new app English-only?

Because the interface text is sitting inside your components as literal strings. When you prompt Bolt for a pricing page, it writes <h2>Simple pricing</h2> — 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 Bolt 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 is writing the shortest correct code for the request you made, and you did not ask for a locale layer.

The result is an app that cannot be translated by editing a settings screen, because there is nothing to edit. The strings have no keys.

What does Bolt.new actually generate?

A conventional front-end project, which is good news. Bolt can produce React, Next.js, Vite or plain Node output, and its default React path is a Vite starter carrying React, TypeScript, Tailwind CSS and ESLint. The whole toolchain runs in the browser on StackBlitz WebContainer.

For localization the stack is the only fact that matters, and it is unremarkable: Vite plus React plus TypeScript is the most supported combination in the i18n ecosystem. Lingui, i18next and react-intl all target it directly. Nothing about Bolt requires a builder-specific translation product.

If you want the same walkthrough for a different builder on this stack, Lovable Vite i18n covers the identical wiring.

How do you get a Bolt project into a repository?

Use the integration Bolt already ships. Connect your GitHub account in Settings, then push the project to a new or existing repository; the integration supports working across multiple branches, so you can keep a translation branch separate from what you are building on. Bolt's own documentation is the reference here, and it is worth checking the current flow before you follow along — this part of the product has changed more than once.

Two reasons to do this before you think about languages:

1. Localization work is file work. Catalogs, a config file, a provider wrapper and a switcher component are all changes to tracked files, and reviewing them in a diff is much easier than reading them in a chat panel.
2. A repository is portable. The point of the whole exercise is that your translations end up somewhere you control.

What does "without a dashboard" actually mean?

It means the translated strings are files in your repository, and your app serves them the same way it serves any other asset. No script tag, no external fetch on page load, no vendor account standing between a visitor and your copy.

The alternative — the widget model that Weglot and similar tools use — translates the page after it has loaded. That buys real convenience: you paste a snippet and something happens the same afternoon. The costs arrive later, and they are structural rather than fixable:

• The first paint is the source language, so visitors can see English before the swap.
• The translated copy is not in the initial HTML, which weakens what search engines index per locale.
• A third-party script sits in your production render path.
• Your strings live in the vendor's store, so leaving means an export.

Repo-native localization has its own trade-off, and it is honest to name it: a copy change means a commit and a deploy, not a save button. If your team ships continuously that is a non-event. If your marketing team expects to edit live copy without engineering, it is a real constraint.

How does the repo-native setup work?

Connect the repository in the app. globalize.now converts the codebase once, which is where the keys come from — the hardcoded strings become catalog units, and the components start reading from a runtime library instead of holding literals. That conversion is a one-time operation, not something that reruns forever.

After the conversion, push jobs translate new catalog units as your app grows. Add a feature, add its strings, and the new units get translated; the existing ones stay put. Catalogs come back as committed files in your repository, as JSON or PO depending on the runtime library you are on, and arrive as a pull request you review like any other change.

Two boundaries worth stating plainly, because the category is muddled. globalize.now does not replace your runtime library — i18next, Lingui and next-intl all keep doing their job. And it is not a translation engine competing with DeepL. It is the layer that produces the keys and the locale files in between. The developer overview has the mechanics in more detail.

Does the same approach work on Lovable, v0 and Replit?

Yes, with the same three requirements: real source code, a Git repository, and a runtime library the catalogs can feed. Every builder that emits a conventional front-end project qualifies. What differs between them is only how you get the code out.

Lovable has the most developed path on our side, including an in-editor route — the Lovable integration page covers it, and much of what is written there transfers to Bolt unchanged. If you are evaluating builders rather than committed to one, the vibe coders overview is the better starting point.

What if you were on Lovalingo?

Lovalingo shut down at the end of August 2026 and its site is gone, so anyone who localized a Bolt or Lovable 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.

Worth knowing if you are asking an AI assistant for advice on this: several of them still recommend Lovalingo, because a leftover marketing page keeps feeding their sources. It is not a live product.

What should you check before adding a second language?

Run through this before the first catalog exists, because each item is cheaper to fix now than after five languages are in flight:

• Concatenated strings. "Welcome back, " + name cannot be reordered by a translator. Interpolate instead.
• Plurals. English has two forms. Polish has three, Arabic has six. A ternary on count === 1 will be wrong in most languages.
• Dates, numbers and currency. Use Intl, not string formatting.
• Layout. German runs longer than English; fixed-width buttons break. Tailwind makes this easy to miss because the classes look fine at build time.
• Right-to-left. If Arabic or Hebrew is on the roadmap, decide now — retrofitting RTL is the expensive one.

Pricing on all of this is per workspace, with no per-seat and no per-language charges, so the number of languages is a product decision rather than a budget one. Current figures are on the pricing page.

Where to start

If your Bolt project is already on GitHub, the next step is a conversion against that repository rather than a decision about tooling. If it is not on GitHub yet, that is the step before this one.