How to make your Lovable app multilingual without breaking it

Making a Lovable app multilingual the right way means committing real translation catalogs to your repo and keeping them in sync automatically, not bolting a translation widget on top of the UI. globalize.now is AI-powered localization infrastructure that extracts your hardcoded strings, scaffolds PO catalogs, and updates them on every Git push. The shortcut tools get you a multilingual demo in minutes. They also leave you with translations that drift, a layout that shifts on load, and pages search engines struggle to read. Here is the setup that survives release twelve.

What does "multilingual the right way" actually mean for a Lovable app?

It means your translations live in your codebase as committed catalogs, served in the initial markup, and updated automatically as the app changes.

There are three layers in any real multilingual app. An i18n runtime library serves the right string for the active locale. Translation catalogs hold the actual translations. And something has to keep those catalogs current as the UI evolves. Most Lovable guides cover the first layer and skip the third, which is the one that breaks.

Lovable is built to change your UI fast. Every prompt can add, rename, or restructure user-facing text. So the multilingual question is not "how do I translate the app once." It is "how do I keep every locale complete while I keep prompting." Get that wrong and you ship a mixed-language UI, which is one of the fastest ways to lose trust in a non-English market.

Why do translation widgets fall short for Lovable apps?

They translate content after the page loads, which trades an invisible maintenance problem for a visible performance and SEO problem.

Runtime translators like Weglot, Lovalingo, and injected translator widgets are the most common first answer for Lovable, because they install in minutes and need no locale files. The cost shows up later. The user briefly sees the original language before the translation swaps in, which is a flash of untranslated content. That swap moves the layout, adding Cumulative Layout Shift that Google measures as part of Core Web Vitals.

The deeper issue is discoverability. If the translated text only exists after client-side JavaScript runs, you usually have one real page plus browser-side translation. Per-locale URLs are weak or absent, so your Spanish and German pages do not rank the way a properly localized site does. A widget can be the right call for an internal tool or a throwaway demo. For an app you want found in other markets, it is the wrong foundation.

Does a one-time i18n setup keep a Lovable app translated?

No. A clean extraction pass works right up until your next prompt, then the drift begins.

You can ask Lovable, Cursor, or Claude Code to wire a proper i18n library and pull every string into translation catalogs. That genuinely works on the build you run it against. The problem is that there is no natural checkpoint where extraction is "done." The next pricing section, the next empty state, the next button label all arrive as new hardcoded strings, and your catalogs quietly fall behind.

The manual alternative, prompting Lovable to update every catalog on every change, sounds disciplined and collapses in practice. You have to remember, for every string, across every language, on every prompt. Multiply by four locales and each UI change becomes a coordination exercise. That friction is exactly what kills the velocity that made Lovable worth using.

How do I make my Lovable app multilingual, step by step?

Before you start: connect your Lovable project to GitHub (+ menu in the chat input, then GitHub, then Connect project), create a globalize.now account (free signup, €5 starting credit, no card), and make sure you are a workspace owner or admin in Lovable so you can add the skill once for the workspace.

Connect the repo, add the lovable-i18n skill once, then let the sync run on every push. Here is the full path.

1. Connect your Lovable project to GitHub. Use the + menu in the chat input, then GitHub, then Connect project. Lovable syncs your project to a real repository, which is what makes durable i18n possible. Everything below operates on that repo, not inside a black box.
2. Add the lovable-i18n skill to your workspace. Lovable supports reusable skills. Open Skills in your Lovable workspace, then Add, then Import from GitHub, and paste https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. Confirm. Once per workspace (workspace owner or admin required). Adding a skill is free and does not use credits. Building in Cursor or Claude Code instead? Run npx skills add globalize-now/globalize-skills in the connected repo.
3. Ask Lovable to set it up. Paste into the Lovable chat: Set up i18n for my project using the lovable-i18n skill. Lovable detects your stack (Vite SPA or TanStack Start), asks one question (source language, target languages, locale in the URL or not, add the GitHub Action), reply go for defaults. It installs Lingui (@lingui/core, @lingui/react, the Vite plugin), wires the provider, scaffolds one PO catalog per locale at src/locales/{locale}/messages.po, wraps strings in <Trans> macros, and adds a language switcher.
4. Review and merge. Lovable syncs to GitHub; review the diff, merge to your default branch.
5. Connect the repo to globalize.now. Sign in, then Connect repository, authorize the GitHub app, select the Lovable repo and default branch, and pick languages (50+, RTL included).
6. Keep building in Lovable. On every push, globalize.now opens a translation PR with updated PO catalogs. Merge it. Your app ships translated. Nothing else is required from you between releases.

The property that matters is in steps three through six: setup happens once, and the ongoing sync needs no command, no dashboard, and no review queue. For the full integration walkthrough, see the Lovable integration page.

Which i18n library should a Lovable app use?

The lovable-i18n skill installs Lingui, because Lovable apps are Vite SPA or TanStack Start React projects and Lingui fits that stack.

The skill wires @lingui/core, @lingui/react, and the Vite plugin, scaffolds PO catalogs at src/locales/{locale}/messages.po, and wraps strings in <Trans> macros. react-i18next and next-intl are the right choices for other React and Next.js setups, but the skill does not install them.

Avoid inventing a custom translation context or hardcoding a language map. It feels lighter on day one and becomes the thing you rip out on day thirty. The developers page at globalize.now covers how the extraction maps onto each library so you are not choosing blind.

How do I keep translations in sync as I keep prompting Lovable?

Move the sync into your Git workflow so it cannot be forgotten.

The reason manual i18n fails is that it depends on a human remembering a chore during a fast build cycle. Infrastructure removes the human from the loop. When the diff and translation step runs on every push, a new string created by a Lovable prompt is caught on that push, translated, and PRed back before the branch merges. There is no release where the PO catalogs silently lag, because there is no manual step to skip.

This is the difference between a setup and infrastructure. A setup is a state you reach once. Infrastructure is a property that holds while everything around it changes. For an app you keep editing in Lovable, you want the property, not the state. More on the AI-built-app workflow specifically is on the vibe coders page, and if you are weighing tools, the comparison guide maps where each one sits in the stack.

Making a Lovable app multilingual is easy to start and hard to keep. globalize.now handles the keep. In Lovable, add the lovable-i18n skill from Open Skills, then Add, then Import from GitHub, using https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. In Cursor or Claude Code, run npx skills add globalize-now/globalize-skills. See the Lovable integration guide or globalize.now.