How do I export my translations from Lovalingo before it shuts down?

Request your preservation export from Lovalingo now, then convert the translation bundles into PO catalogs committed to your own repository. Lovalingo is preparing exports for active projects, and support runs through [email protected] until the service closes on August 31, 2026 at 23:59 CEST. globalize.now is AI-powered localization infrastructure: it takes the strings you rescued, generates locale files in your repo, and keeps them in sync on every Git push, so this is the last translation export you will ever need to do.

What happens to my translations when Lovalingo closes on August 31?

Every language except your source language stops rendering, because the translated text was never in your app to begin with. Lovalingo is a runtime layer: your Lovable app ships in English, and their service swaps the text per visitor. When the service stops, the swap stops.

The closure terms are public on Lovalingo's service-closure page. New projects and subscriptions are already off. Active projects keep working until August 31, 2026 at 23:59 CEST. Billing collection is paused, and preservation exports are being prepared for active projects.

That deadline is really a data deadline. After the cutoff there is no service to export from, and no support inbox to ask. If your app earns traffic in French or German today, the work that produced those translations evaporates unless you pull it out first.

How do I get my translation data out of Lovalingo?

Ask for your preservation export and secure it alongside your source repository. Per the closure page, the exports contain the project's available configuration, routes, translation bundles, overrides, and integrity evidence: everything the runtime knew about your languages.

1. Request the export. Exports are being prepared for active projects. If yours has not been delivered, email [email protected] and ask for export delivery for your project.
2. Preserve two things together: the export file and a snapshot of your current source repository. The export describes the translations; the repo is the app they belong to.
3. Do not uninstall Lovalingo yet. Their own guidance says to keep it installed until your replacement passes production checks. The two systems can run side by side during the switch.

The translation bundles are the part that matters most. They hold the actual translated strings per locale, plus any manual overrides you made in their dashboard. Overrides are the piece people forget: those edits exist only in Lovalingo, not in any machine-translation engine you could re-run.

How do I convert Lovalingo bundles into catalogs my repo owns?

Turn the bundles into gettext PO catalogs and commit them. PO is plain text, diffs cleanly in Git, and is the format Lingui compiles for React apps, which covers both stacks Lovable generates: classic Vite SPA and the newer TanStack Start SSR default.

Runtime bundles are typically key-value maps per locale. A conversion is a small script, not a project:

// convert.mjs — JSON bundle → PO entries
import fs from "node:fs";

const locale = process.argv[2]; // e.g. "de"
const bundle = JSON.parse(fs.readFileSync(`bundles/${locale}.json`, "utf8"));

const po = Object.entries(bundle)
  .map(([source, translated]) =>
    `msgid ${JSON.stringify(source)}\nmsgstr ${JSON.stringify(translated)}\n`)
  .join("\n");

fs.writeFileSync(`src/locales/${locale}/messages.po`, po);

Exact field names vary by export, so check yours before running anything. The principle does not vary: source string in, msgid/msgstr pair out, one .po file per locale, committed under src/locales/.

If hand-rolling the conversion is not your thing, the Lovalingo migration guide covers the managed path, and there is three months of usage free for Lovalingo migrators through the closure window.

How do I wire the rescued catalogs into my Lovable app?

Add the lovable-i18n skill to your Lovable workspace, then prompt Lovable to set up i18n; the skill wires Lingui to your stack and picks up the PO catalogs you committed. Outside the Lovable editor, the same setup installs with:

npx skills add globalize-now/globalize-skills

Which stack you are on decides the wiring details. Apps generated before May 2026 are mostly classic Vite SPAs; newer ones default to TanStack Start with SSR. There is a dedicated walkthrough for each: i18n for Lovable Vite apps and i18n on Lovable's TanStack Start stack. The Lovable integration page covers what the skill does end to end.

From that point the maintenance problem Lovalingo solved at runtime is solved in your repo instead. New strings you ship get extracted, translated, and committed as a translation PR on every push. Pricing is €20/month per workspace, which includes €20 of translation credit (about 200,000 words) a month, then token-based usage at the same per-character rate: no per-seat charges and no per-language charges, so adding your sixth locale costs the same as your second. Built for vibe coders who never want to think about locale files.

What should I test before removing Lovalingo?

Test the replacement in production conditions first; removal is the last step, not the first. Lovalingo's own pre-removal sequence is a good checklist, and it maps directly onto a committed-catalog setup:

• Direct locale URLs. Every language should live on a real route (/de/, /fr/) that loads on a hard refresh, not only via client-side switching.
• Missing keys and fallbacks. Delete a translation locally and confirm the app falls back to the source string instead of rendering blanks.
• SEO metadata per locale. Check titles, descriptions, canonical URLs, hreflang pairs, and the sitemap for each language. Server-rendered locale routes make these visible to crawlers without a JavaScript pass, which the make your Lovable app multilingual guide walks through.
• Only then remove the widget. Once the committed-catalog version passes, take Lovalingo out and re-run the checks.

One quiet upside of the switch: nothing on this checklist can regress because a vendor changes plans. The catalogs are files in your Git history now.

Your export is a one-time rescue. globalize.now makes it the last one: set it up once and your catalogs stay extracted, translated, and committed on every Git push.