Home Getting Started I already have i18n or a translation tool — what happens when I connect?

I already have i18n or a translation tool — what happens when I connect?

Last updated on Sep 16, 2026

If your codebase already has next-intl, react-i18next, i18next or @lingui/* wired up — or you're moving from Lokalise, Crowdin or Phrase — globalize.now doesn't set anything up from scratch. It connects to the locale files you already have and keeps them translated on every push. No language switcher injection, no restructured keys, no changes to routing or framework config.

What happens when you connect

  1. Sign in and connect the GitHub or GitLab repo. The scan reads your repo and detects the existing setup from signals like an i18n library in package.json, a messages/ or locales/ folder, and an existing source-locale file. Two or more of those and your project is treated as already internationalised. Confirm the detected framework and locale path patterns (for example messages/{locale}.json); a non-standard folder layout is a one-line setting.

  2. Choose what to do with the translations already in the files. In Project → Settings → Existing translations:

    • Import as already approved — we trust them, mark them approved and add them to your translation memory. Nothing you've already paid for is re-translated or billed. The right choice when you're leaving a tool you were happy with.
    • Import for review — we keep them, run the quality-review pass, and you approve them before they count.
    • Ignore them — translate everything from scratch.

    Then choose whether to import only strings we haven't seen before (default) or every string, on every push, which makes your files the source of truth on every push.

  3. Pick your watched branches. From the next push with new or changed source strings, a job runs and a pull request (or merge request) lands with only the locale files that changed. Review, merge. Turn on Auto-discover target locales if a new locale file appearing in the repo should become a target language automatically.

What we never touch on an existing setup

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

Half-migrated apps (t() calls on new components, hardcoded strings on old ones) are handled: what's already wrapped is preserved, and only the rest can be extracted if you ask for it.

Moving from Lokalise, Crowdin or Phrase

  1. Export every language from the old tool in the format your app uses (JSON, .po, …) and commit the files where your app expects them. Most teams already have this — it's the sync those tools run into your repo.
  2. Connect the repo and set Existing translations → Import as already approved.
  3. Export the old tool's glossary and import it into Project → Glossary.
  4. Cancel the old tool. There is no parallel dashboard to keep in sync: the repository is the source of truth and the translation memory is built from what's in it.

What doesn't carry over: comments, screenshots and task workflows from the old tool — those lived in its dashboard, not in your files.

If you use the agent path instead

Running the setup through your own coding agent with the globalize skills? The globalize-guide skill inspects the repo first and, when it sees an existing i18n setup, proposes connect-only mode and shows you the plan before changing anything.

If the plan instead proposes installing a library, adding a language switcher and rewriting components, detection missed your setup. Don't approve that plan. Tell the agent:

This project already uses [your i18n library]. Connect it in sync mode instead of setting up i18n from scratch.

Already approved a plan that did too much? It's recoverable:

git restore .
git clean -fd

If you committed but didn't push: git reset --hard HEAD~1. Then re-run and correct the plan before approving.

If detection keeps missing your setup, send us your package.json dependencies and locale folder layout at support@globalize.now — we use it to improve detection.

Where to go next