Lovalingo is shutting down: how do you migrate your Lovable app?

Lovalingo is closing on August 31, 2026, and because it translates your app through its runtime service, your multilingual site shuts off with it unless you migrate first. The fix is the one Lovalingo's own closure guidance recommends: project-owned internationalization. globalize.now is AI-powered localization infrastructure that does exactly that for Lovable apps. It extracts your UI strings into Lingui PO catalogs committed to your repository and syncs a translation PR on every Git push, so your languages survive any vendor's shutdown, including this one. And because this migration isn't one you chose, Lovalingo migrators get their first three months of usage free. Below: what breaks, what to save, the migration itself, and the removal steps most guides skip.

What did Lovalingo announce?

Lovalingo announced it will close on August 31, 2026 at 23:59 CEST, and it has already stopped accepting new projects and subscriptions. The announcement runs as a site-wide banner on lovalingo.com with a dedicated service-closure page. The service is operated by Tempo AI LLC.

The terms are orderly. Billing collection is paused for active subscriptions, access continues until the cutoff, and preservation exports are being prepared containing project configuration, routes, translation bundles, and overrides. Migration support runs through [email protected].

Two details matter more than the rest. First, no successor is named, so users are not being handed to another vendor. Second, the official migration guidance tells you to implement project-owned internationalization alongside Lovalingo before removing it. That is a specific architectural instruction, and it rules out replacing one runtime translation widget with another.

What happens to your app when Lovalingo shuts down?

Your app reverts to its source language. Lovalingo works as a runtime layer: you install @lovalingo/lovalingo, wrap your app in its provider, and translations are served through their infrastructure. No locale files exist in your repository. When the service stops responding, your build still compiles and deploys, but every page renders untranslated.

There is one sharper failure mode. Lovalingo's recommended sitemap setup adds a prebuild script that downloads your sitemap from Lovalingo's CDN and is designed to fail the build if that download fails. Once the CDN goes offline, projects with that script stop building entirely. Check your package.json for a prebuild entry fetching from cdn.lovalingo.com. If it is there, removal is not optional cleanup, it is what keeps you shipping.

The SEO damage is the slower cost. Lovalingo generated your locale URLs and hreflang tags at runtime; after the shutdown those translated pages stop existing, and search engines deindex what they can no longer crawl. We made the structural argument in our comparison of Lovalingo, Weglot, and globalize.now back in June: with any runtime translation service, your multilingual site exists only while the vendor does. That was a hypothetical then. It has a date now.

What should you do before August 31, 2026?

Secure your data now, and keep Lovalingo running while you stand up the replacement. Do not wait until late August: the support queue at [email protected] will be busiest in the final week, and you want slack for a failed production check. A sane target is having the migration done by August 24, a full week of buffer.

Lovalingo's closure page lays out the sequence itself, and it is the right one:

1. Preserve your project export and your current source repository. If your export has not arrived, request it from [email protected] today.
2. Note your current language list and locale URL structure. They are in your LovalingoProvider configuration and the export. You will mirror both.
3. Implement project-owned internationalization alongside Lovalingo. Do not remove anything yet.
4. Test direct locale URLs, page refreshes, missing keys, and fallback behavior on the replacement.
5. Remove Lovalingo only after the replacement passes production checks (full removal checklist below).

Note what step 3 asks for. Project-owned means the translations live in your repository as files you control, not in another vendor's runtime. Moving from Lovalingo to a second runtime widget puts you one shutdown away from doing this migration again. The Lovalingo compare page walks through the two architectures side by side.

How do you migrate from Lovalingo to globalize.now?

For a typical Lovable app the migration is one working session, not a rebuild, and you never leave the Lovable editor:

1. Add the skill. Add lovable-i18n in your Lovable workspace, or from a terminal: npx skills add globalize-now/globalize-skills. The Lovable integration page documents the flow.
2. Prompt Lovable to set up i18n. Something as simple as "Set up i18n for this app using the lovable-i18n skill" works. The skill guides Lovable to wire in Lingui, extract your hardcoded strings, and create PO catalogs: plain files committed to your repo.
3. Match your Lovalingo setup. Configure the same target languages and the same locale path structure (/de/..., /fr/...) you ran on Lovalingo, so your already-indexed URLs stay live. If any path must change, add a 301 redirect.
4. Push. globalize.now picks up the catalogs and opens a translation PR covering your target languages. Merge it and your languages are back, this time as files in your repo.
5. Test with Lovalingo still installed. Run their own checklist: direct locale URLs, refreshes, missing keys, fallbacks, per-locale metadata. New Lovable projects ship on TanStack Start with SSR, so your locale routes arrive as server-rendered HTML; older client-rendered React projects work too, since the catalogs live in your repo regardless of rendering mode.

Prefer to watch the install once before doing it? The whole flow, from adding the skill to merged translation PR, is three minutes:

From then on the loop is: set it up once, auto-sync on every Git push, no manual intervention required. Pricing is €20 per month per workspace with unlimited projects and languages, around 4,000,000 characters included monthly, and a €5 signup credit with no card required.

For Lovalingo migrators there is a standing offer on top: your first three months of usage are free. The migration wasn't your choice, so the first stretch shouldn't cost you anything. To claim it, sign up and email [email protected] mentioning your Lovalingo project, and we apply it to your workspace.

How do you remove Lovalingo cleanly?

Removal is more than uninstalling a package, because Lovalingo wires into your router and your build. Work through this checklist once your replacement passes testing; each item applies only if your setup includes it:

1. Restore your router. In path mode, Lovalingo's LangRouter replaces BrowserRouter. Put your original router back when you remove it, or the app won't render.
2. Fix internal links. If your code uses Lovalingo helpers like LangLink or useLangNavigate, replace them with your router's own Link and navigation. Those imports break the moment the package is gone.
3. Remove the provider and package. Delete LovalingoProvider (and LangRouter) from your app shell, then uninstall @lovalingo/lovalingo.
4. Delete the manifest. Remove /.well-known/lovalingo.json from your public directory or the endpoint that generates it.
5. Remove the sitemap prebuild step. If scripts/fetch-lovalingo-sitemap.mjs and a prebuild entry exist in package.json, delete both. This is the script that fails your build once their CDN dies. Serve your own sitemap instead; with committed locale routes it is generated from your codebase.
6. Redeploy and resubmit. Ship the cleaned build, confirm locale URLs render translated, and resubmit your sitemap in Google Search Console so the rebuilt pages get recrawled.

Ten minutes of cleanup, and the last runtime dependency on a closing service is gone.

Can you keep your existing Lovalingo translations?

Keep the export. It is useful as a reference, not as a drop-in import. globalize.now translates from your source strings and commits the results to your repo, so your languages come back within one push. Where you had hand-tuned Lovalingo overrides for specific phrases or product terms, carry those into your globalize.now glossary and manual edits so the wording you cared about survives the move.

The honest trade: you are re-generating translations rather than porting a vendor's bundle format. What you get in exchange is that this is the last migration of its kind. The output is PO files in your repository, portable by definition.

What if your app isn't built with Lovable?

The same migration works. Lovalingo also served React, Next.js, v0, Bolt, and Claude Code projects, and globalize.now covers those through the same skills package: install it for your agent, let it extract strings to Lingui catalogs, push, merge the PR. The flow for developers and vibe coders is identical to the Lovable path minus the Lovable editor. The removal checklist above applies unchanged, and so does the three-months-free migration offer.