What project types and frameworks are supported?

Supported frameworks

globalize.now works with React-based web apps. Current first-class support:

Note on Lovable: Lovable projects now use TanStack Router by default. This is fully supported.

What's not in scope yet

Blog content: globalize.now extracts UI strings from your app — buttons, labels, headings, form fields. It doesn't translate blog posts, documentation, or long-form content. If your project has both a web app and a blog, the tool handles the app and skips the blog.

If your project includes components outside the supported scope, the agent focuses on the React web app and skips unsupported parts. It won't fail — it just won't touch those files.

Corporate VPN and enterprise environments

globalize.now does not work on corporate VPN or in enterprise environments that restrict external connections. The npx skills install step and the GitHub connection both require external network access.

Workaround: Use a personal machine or a personal GitHub account.

Monorepos

globalize.now works on monorepos. The agent focuses on the React/Next.js parts and ignores non-web code. To scope the conversion:

Convert only the /apps/web directory

Partially internationalized codebases (L1 state)

If your app already has an i18n library wired up — next-intl, react-i18next, i18next, or @lingui/* — globalize.now detects that on first run and skips the setup scaffold. No language switcher gets injected. Your existing locale file structure is preserved. The agent moves straight to sync mode.

What we detect

On first run, the agent reads your repo for any of:

• package.json dependencies: next-intl, react-i18next, i18next, @lingui/core, @lingui/react, @lingui/macro, or any i18next-* plugin.
• Locale folders: messages/ or locales/ at the repo root, or src/i18n/ with locale subfolders.
• Existing locale files: en.json, en.po, en.yml, en.yaml, or whichever default-locale file your library expects.
• Framework config: i18n.config.ts, next-intl middleware, lingui.config.js, or equivalents.

If at least two of these are present, the project is treated as L1.

What we skip in L1 mode

• No string-extraction pass across your components
• No new translation keys or restructuring of your existing key tree
• No locale files scaffolded for languages you haven't already set up
• No language-switcher component injected into your UI
• No changes to your routing, middleware, or framework config

What we do

L1 mode is sync-only. Connect your GitHub repo, the agent reads your existing locale files to learn your key structure and source language, and on every push to main we diff the source-language file against the other locales. Missing translations get translated. A PR lands with the updated locale files. You review and merge.

Mixed L1 (some keys, some hardcoded strings)

Some apps are halfway through their i18n migration — t() calls on the new components, hardcoded strings on the old ones. The agent detects what's already wrapped and only extracts what isn't. Existing keys are preserved.

Non-English source languages

globalize.now uses whatever language your app is currently written in as the source. The agent auto-detects it.

Detection edge case: If your site contains mixed-language content, the agent may occasionally mis-detect the primary source language. Correct it in your globalize.now project settings before translating.

File formats

globalize.now generates locale files in the format your i18n library expects:

You don't need to choose — the agent detects your library and generates the right format.