How do you localize a Lovable app without a dashboard?

You localize a Lovable app without a dashboard by keeping every piece of the workflow in the repository: message catalogs as committed files, a config file that names your locales, and a CLI step in your build that compiles them. globalize.now is AI-powered localization infrastructure that runs that loop for you, extracting strings from your codebase, generating keys and locale files, and syncing translations on every Git push. Nothing in the chain requires a browser interface, which matters more than it sounds when the thing writing your code is an agent.

Why does a dashboard break an AI-built workflow?

Because your agent cannot open one. Lovable, Cursor, Claude Code and Copilot all operate on the same two surfaces: files in a repository and commands in a terminal. A dashboard is neither.

That gap is now a documented assumption rather than a preference. AGENTS.md, the convention for telling coding agents how a project works, was contributed to the Linux Foundation's Agentic AI Foundation in December 2025 alongside Model Context Protocol. Per the Linux Foundation's own announcement, more than 60,000 open-source projects had adopted the format by then, across more than twenty AI coding tools. The whole premise is that project instructions belong in a file the agent can read.

Translation state that lives behind a login sits outside that premise. When your agent adds a new button to your Lovable app, it can add the string. It cannot then log in somewhere and reconcile a translation grid. So the string ships in English, the mismatch accumulates, and you find out from a user in Germany.

There is a second failure that is quieter. When corrections only exist in a vendor's interface, the repository is no longer the truth about what your app says. Two sources of truth, one of which your tooling cannot inspect, is a debugging problem waiting for a deadline.

What does a no-dashboard Lovable setup actually look like?

Four files and one command in your build. Lovable's generated apps ship as React, either on the classic Vite stack or on TanStack Start with server rendering, and both take the same shape.

1. Name your locales in config. One file, committed, is the list every other layer reads from.

// lingui.config.ts
import { defineConfig } from "@lingui/conf";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "de", "es", "fr"],
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

2. Extract messages into catalogs. lingui extract scans your source and writes one .po catalog per locale. It merges with what is already on disk, so existing translations survive a re-run, the property that makes this safe to put in an automated loop.

npx lingui extract

3. Compile before you build. lingui compile turns the catalogs into runtime modules. The --strict flag fails the build when a translation is missing, which converts a silent English fallback in production into a red build you see first.

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. Let the sync run on push. Adding a locale should be an edit to the locales array, not a support ticket. globalize.now watches the repository, extracts strings the agent introduced, generates the keys and catalog entries for every locale, and commits them back. The catalogs arrive as a diff in a pull request, reviewable like any other change.

The full per-stack walkthroughs live in the Lovable Vite guide and the TanStack Start guide.

What happens to dashboard-managed translations when the vendor shuts down?

They leave with the vendor. This is not hypothetical this month: Lovalingo, a runtime translation service built for Lovable and other AI-builder apps, closes on August 31, 2026 at 23:59 CEST. New projects and subscriptions have already stopped, and the company's own closure page tells customers to implement project-owned internationalization alongside the service before removing it, then verify locale routes, fallbacks, canonical URLs, hreflang and sitemap output.

That is a vendor describing, accurately, the difference between renting a workflow and owning one.

The last row has an SEO consequence that outlives the vendor question. Translations injected after load are not reliably in the HTML a crawler reads. Catalogs compiled into your build are.

How do you check your Lovable app has no dashboard dependency?

Three checks, each of which fails loudly.

Check the network. Load your app with DevTools open, filter to scripts, and look for requests to a translation vendor's domain. If a third-party script has to load before your German page reads as German, your German page depends on someone else's uptime.

Check the repository. For every locale in your config, a catalog file should exist on disk and be tracked by Git. Run git ls-files "src/locales/**" and count. Empty or missing catalogs mean the strings are somewhere else.

Check the build. Compile with --strictin CI. A missing translation should stop a deploy. If your build passes while a locale is incomplete, the gap will surface as English text in a non-English UI, which is the failure mode users report as "the site is broken".

Run all three against a preview deploy before removing any existing vendor, not after. Lovalingo's own pre-removal checklist makes the same point: keep the old service installed until the replacement has been tested on real locale routes. Our Lovalingo comparison covers the migration path directly.

Where does globalize.now fit if there is no dashboard?

In the layer between your i18n runtime and your translation engine. Libraries like Lingui, i18next and next-intl serve translations at runtime. Engines like DeepL and GPT translation produce the text. globalize.now generates and maintains the thing in the middle: the keys and locale files, kept current with the code.

That layer is exactly the one that used to require a person clicking through an interface, which is why removing the interface is a workflow change rather than a feature loss. Setup happens once: connect the repository at globalize.now and the conversion arrives as a pull request. In your editor, the same setup is one command:

npx skills add globalize-now/globalize-skills

Inside Lovable, the same capability installs as an in-editor skill, so the agent building your app can invoke it directly. The Starter plan is €20 per month per workspace, including €20 of translation credit (about 200,000 words) per month, with usage above that billed at the same per-character rate. No per-seat and no per-language charges, and a €5 signup credit with no card. Languages and projects are unlimited inside a single workspace, which is the part that matters when you are adding a fifth locale rather than a fifth seat.

More on the surrounding workflow for vibe coders and developers, and the Lovable-specific setup on the Lovable integration page.

The short version

Your Lovable app's translations should be files you own, in a repository your agent can read, compiled by your own build. globalize.now keeps those files current on every Git push.