What project types, frameworks and file formats 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.

Beyond React web apps

Two jobs, two answers. Setting up i18n in your code (extracting strings, installing the library) works on the React web apps above. Keeping locale files translated works on any project whose locale files are in a supported format, including mobile apps and browser extensions: connect the repo and point the locale path pattern in project settings at those files.

Long-form content: globalize.now started with UI strings — buttons, labels, headings, form fields. Markdown and long-form content (blog posts, documentation) is rolling out now; ask support to enable it on your project.

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

Locked-down networks

The in-app flow needs nothing installed locally: connect your GitHub or GitLab repository and translations arrive as pull requests. The optional npx skills install and the MCP server need outbound access to npm and globalize.now, which some corporate networks block — if that's you, use the in-app GitHub flow.

Monorepos

globalize.now works on monorepos. Create one project per app and point its locale path patterns (project settings) at that app's locale files, e.g. apps/web/messages/{locale}.json. 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 or GitLab repo, globalize.now reads your existing locale files to learn your key structure and source language, and on every push to a watched branch it diffs 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

When globalize.now sets up i18n in your code, it writes the format your library expects:

When it keeps existing locale files translated, these formats are supported:

Locale files are found through the locale path patterns in your project settings (for example messages/{locale}.json or ios/App/Localizable.xcstrings), so a non-standard folder layout is a one-line setting, not a blocker. The same formats work when you hand files to an AI agent through the MCP server.

Using a format that isn't listed? Tell support — it helps us order the roadmap.