What actually happens when you go multilingual in Lovable

You prompt Lovable to add a new pricing section. Lovable generates the component, wires it in, and ships it. Your English UI is updated. Your fr.json and de.json still point to whatever was there before. French users see the old text. German users see English. Nobody catches it until a real user reports it.

This isn't a Lovable bug. It's a structural mismatch. Lovable optimizes for shipping UI fast. i18n requires tracking every user-facing string across every locale file, on every change. Those two goals are in direct tension with each other.

The extraction problem is continuous, not one-time. Every prompt Lovable runs can create new strings. Every iteration changes existing content. There's no natural checkpoint where you can say "extraction is done."

Why the obvious fixes don't hold

Does a one-time extraction run fix it?

No. You can run a string extraction pass after your initial Lovable build and create clean locale files. That works until the next prompt. After that, you're manually comparing diffs across potentially dozens of components and dozens of locale files. One missed string in es.jsonand your Spanish users get English text in the middle of a translated page — what's known as a mixed-language UI, one of the most trust-destroying experiences you can ship.

Are runtime translation tools good enough?

Runtime translators like Weglot or JavaScript-injected translation widgets solve a different problem. They translate content after the page loads, which means users see the original language for a fraction of a second before the translated content appears. Beyond the poor user experience, this creates measurable Cumulative Layout Shift — a Core Web Vitals signal that Google uses to rank pages. You're trading an invisible maintenance problem for a visible performance problem.

What about just prompting Lovable to update the locale files?

Lovable can write to locale files if you ask it to. The problem: you have to remember to ask, for every string, on every prompt, across every locale. The cognitive overhead compounds with each language you add. Multiply by four locales and you've turned every UI prompt into a four-step coordination exercise. That's exactly the kind of friction that kills the velocity that made Lovable worth using.

How the Lovable i18n cycle actually breaks down

The pattern is consistent enough that it has a recognizable shape:

  1. Initial setup — You add multilingual support. It works. Everything is translated. You feel good.
  2. First few releases— You remember to update locale files manually. It's annoying but manageable.
  3. Velocity phase— You start shipping faster. Locale files start lagging behind. You tell yourself you'll catch up.
  4. Mixed-language production — Users in non-English markets start seeing partial English. Support tickets arrive. You spend a release cycle doing nothing but hunting strings.
  5. Refactor tax— Every new feature now has a hidden i18n cost that didn't exist in the English-only version. Your release velocity drops.

The refactor tax is the part nobody talks about when they write "here's how to go multilingual in Lovable" guides. The guides show the initial setup. They don't show what happens on release 12.

The fix: i18n wired into your Git push cycle

The correct architectural answer is to remove manual steps entirely. If translations update automatically on every push, the maintenance problem disappears. You can't forget to run extraction if it runs itself.

The workflow looks like this:

  1. Connect Claude Code to your GitHub repository.
  2. Run npx globalize-skills once — this sets up your i18n library, extracts existing strings, generates locale files, and primes your agent to track new strings.
  3. Push to GitHub. globalize.now diffs the new push against the previous locale state, identifies new or changed strings, translates them, and opens a pull request with updated locale files.
  4. Keep building in Lovable. The sync happens in the background on every push.

The key property: step 3 and 4 require nothing from you. You don't run a command. You don't check a dashboard. You don't approve a translation queue. New strings in your Lovable-generated components get caught on the push, translated, and PRed back before you've merged the branch.

What this means for your Lovable workflow

You don't need to stop using Lovable. The architecture is designed around the assumption that your UI keeps changing — that's the whole point. Lovable handles the UI generation. Claude Code handles the i18n setup. globalize.now handles the ongoing sync.

The three tools occupy different layers and don't conflict. Lovable generates components. globalize.now watches the output. Your users always see a complete, translated UI regardless of how fast you ship.

The vibe coders page at globalize.now has more detail on how the setup works specifically for AI-built apps. If you're already running a Next.js or React app built on Lovable, the developers page covers the technical integration path.

For teams already managing multiple Lovable projects, the per-workspace pricing at globalize.now means you're not paying per language or per string extraction — the sync cost stays flat as your app grows.

The maintenance drag is real and it compounds. Run npx globalize-skills in your project or see how it works at globalize.now.