PublishedAugust 27, 2026

How do you translate a Lovable app?

Key takeaways

Runtime widgets translate a Lovable app in minutes, but the text swaps after the English page paints.
Locale files committed to your repo render server-side and survive any translation vendor shutting down.
Lovable generates TanStack Start apps with SSR by default, and Lingui catalogs fit that stack natively.
globalize.now extracts new strings and updates every language automatically on each push, so translations never lag.

You translate a Lovable app one of two ways: attach a runtime widget that rewrites the page after it loads, or wire an i18n library into the generated code and commit locale files to your repo. The widget is faster today. The repo method is the one you still own next year. globalize.now is AI-powered localization infrastructure that automates the repo method: it extracts hardcoded strings from your Lovable codebase, generates the locale files, and keeps every language in sync on each Git push.

What are the two ways to translate a Lovable app?

Every tool for translating a Lovable app is a variant of one of two methods: runtime translation or repo-native i18n.

Runtime translation means a script tag on your published site. The page renders in English, the widget detects the text in the DOM, and swaps it for the visitor's language. Weglot and LocalizeJS work this way, and Lovalingo did until it announced it is closing on August 31, 2026. Your source code never changes; neither does your ownership of the translations, because you never had it.

Repo-native i18n means the strings in your generated code are replaced with translation keys, the translated text lives in catalog files committed next to your components, and the server renders each language directly. On Lovable's stack that is Lingui with PO catalogs, rendered by TanStack Start before any HTML reaches the browser.

The rest of this post walks through both, and what happens to each when the tool behind it disappears.

How do you translate a Lovable app with a runtime widget?

Paste the vendor's script tag into your published Lovable site, pick target languages in their dashboard, and republish. You are done in minutes, and for a marketing page you need in Spanish by Friday, that can be the right call.

The trade-offs arrive later. The page paints in English first and swaps afterward, which visitors see as a flash of the wrong language. Search engines have to trust the vendor's proxy or JavaScript layer to serve the translated version. Pricing scales with languages: Lovalingo, for example, charged for its hreflang SEO features starting at its $9 tier. And the translated text lives on the vendor's servers, not in your project.

That last point stopped being theoretical this summer. When a widget vendor shuts down, every site using it reverts to English the day the script dies.

How do you translate a Lovable app from inside the repo?

Prompt Lovable to wire an i18n library, then connect the repo to globalize.now so the catalogs stay full automatically. Four steps:

Wire the library. Ask Lovable to add Lingui to the project. New Lovable apps have generated TanStack Start with server-side rendering since May 2026; older projects are Vite single-page apps. The setup differs, so follow the per-stack guide: TanStack Start or classic Vite.
Extract the strings. Lingui's extractor pulls every user-facing string into per-locale PO catalog files, committed to the repo like any other source file.
Connect the repo to globalize.now. Install the workspace skill so your AI editor handles the wiring, then link the GitHub repo on the Lovable integration page.
Publish the locale routes and keep building. From now on, every push is scanned: new hardcoded strings are extracted, keyed against your existing catalogs, translated, and committed back. The gap where translations break on every push, the classic failure mode of hand-run i18n in Lovable, never opens.

Outside the Lovable editor, the same workspace skill installs from a terminal:

npx skills add globalize-now/globalize-skills

The result is an app where German or Japanese is not a layer on top of the site. It is the site, rendered server-side on its own URL.

What happens to widget translations when the vendor shuts down?

They stop existing. Lovalingo's closure is the live case: the service ends August 31, 2026, and its own wind-down guidance tells customers to implement project-owned internationalization, which is an argument for committed catalogs made by a widget vendor. If you are migrating from it, the Lovalingo migration guide covers the full path.

Committed PO files fail differently. They are plain text in your Git history. Stop paying for globalize.now and your app still ships every language it has; you have only lost the automation that keeps new strings translated. For vibe coders whose entire product lives in one repo, that is the difference between renting translations and owning them.

How much does it cost to translate a Lovable app?

The globalize.now Starter plan is €20/month per workspace. That includes €20 of translation credit (about 200,000 words) a month; above that, usage continues at the same per-character rate. No per-seat charges and no per-language charges, and a typical app with 10,000 translation keys across 5 locales lands comfortably inside the included volume. Signup comes with a €5 translation credit and needs no card.

Compare that to widget pricing, which typically meters languages and traffic: more markets, higher tier. With unlimited projects per workspace, every Lovable app you spin up shares the same plan. Full detail is on the pricing page, and the engineering view is on the developers page.

globalize.now handles the repo method end to end. Set it up once and every push keeps every language current.

globalize.now turns hardcoded app copy into translation-ready locale files and keeps them updated as you ship.

Try globalize.now free

Was this helpful?

Frequently asked questions

Can I translate a Lovable app without writing code?

Yes. You have two no-code paths. A runtime widget translates the published site with a pasted script tag, but the text swaps after the English page renders and disappears if the vendor shuts down. Or prompt Lovable itself to wire an i18n library, then connect the repo to globalize.now, which extracts and translates strings automatically on every push. You describe the change; the tools write the code.

Does Lovable support multiple languages out of the box?

No. Lovable generates a single-language app; every string it writes is hardcoded English by default. To serve other languages you add an internationalization layer after generation, either as a runtime widget on the published site or as locale files inside the generated TanStack Start or Vite codebase. The repo-based route is the one Lovable's own generated stack can render server-side.

Will translating my Lovable app help it rank in other countries?

Only if the translated pages are real, server-rendered URLs. Search engines index what they fetch, so locale routes rendered from committed catalogs can rank in each market. Widget translations applied after page load are less reliable to index, and their language URLs vanish when the vendor does. Add reciprocal hreflang tags between locales once the routes exist.

Do I lose my translations if I stop using globalize.now?

No. The translations live in plain-text PO catalog files committed to your Git repository, not on globalize.now's servers. Cancel the service and your app keeps shipping every language it already has; you only lose the automatic extraction and translation of new strings on future pushes. That portability is the core difference from runtime widgets.

← Back to blog