Getting Started

How globalize.now works — overview

globalize.now makes your app multilingual in three steps — and keeps it that way on every push. Already have i18n set up? The scan detects locale files and an i18n library, skips the preparation, and connects your existing setup to auto-translate on push. See "I already have i18n. What does globalize.now do?" Free to start. You get a €5 translation credit when you sign up — enough to translate a small-to-medium app across multiple languages before you need to add billing. Step 1 — Sign up and create a project Click Start free at globalize.now, then create a project in the app. Step 2 — Connect your repo Connect GitHub or GitLab and pick the repo. globalize.now scans the codebase and figures out where it stands: not internationalized yet, or already set up. That scan decides the path — you don't configure anything. Step 3 — Preparation, translation, and push — all automatic If the codebase needs it, globalize.now prepares it for multilingual support: extracts hardcoded strings into translation keys, sets up the right i18n library for your stack, and builds the language files. Translations run automatically right after, and everything is pushed to your repo for review. Small projects finish in a few minutes; large codebases can take an hour or more — leave the page open and grab a coffee while globalize does the work. From then on, every push that adds new text gets translated and delivered back as a pull request. You review and merge. No other manual steps, ever. See the whole thing in 2 minutes: the getting-started video. What you get at the end - All UI strings extracted and translated into your chosen languages - Locale files committed to your repo (you own the files, no vendor lock-in) - A language switcher in your app - Automatic translation on every push - The globalize skills installed for your coding agent, ready if you ever want to drive things from Claude Code or Cursor Prefer working from your coding agent? The same result is available from inside Claude Code, Cursor, or Codex using our skills and MCP server — the agent prepares your codebase locally and connects the repo from your editor. Start with "App, MCP, CLI, or skills — which one do I need?".

Before you start: what to expect

Three things to know before you connect a repo: what globalize.now will do to your code, how long it takes, and what access it needs. What will change in your codebase If your repo isn't internationalized yet, the conversion rewrites component files (hardcoded text becomes translation keys), adds an i18n library and its config, creates locale files, and may touch your root layout. That's real, reviewable change — which is why it arrives on its own branch, not on your default branch. You review the diff and merge when you're satisfied. The conversion also installs the globalize skills for your coding agent as part of the process, so the agent side is set up without a separate install. What the conversion actually does Three jobs, in order: 1. Extracts your text. Every hardcoded UI string is found and moved into translation keys — <button>Submit order</button> becomes <button>{t("checkout.submit_order")}</button>. 2. Sets up the i18n framework. The right library for your stack is installed and configured, including the provider wiring your app needs to switch languages. 3. Builds the language files. A source locale file with all your extracted strings, plus files for each target language. After the codebase is prepared, translations run automatically — you don't start them separately. What access it needs You connect through the GitHub or GitLab integration and choose which repositories it can see. globalize.now reads the codebase for the scan and conversion, and pushes results back on a branch. You can restrict it to a single repo. Azure DevOps support is on the way. How long it takes | Step | Typical time | | --- | --- | | Sign up + create project | ~2 minutes | | Connect your repo + scan | a few minutes | | Conversion + translation (if the repo needs preparing) | minutes for small repos, up to an hour or more for large codebases | The conversion runs in the cloud — no terminal, nothing installed. Leave the page open and grab a coffee while it works. The run starts on our fast model and escalates to our Pro model where a file needs more careful handling — automatic, not something you configure. If a run fails, it fails safely: nothing incomplete is pushed to your repo. Keep pushing normally The conversion works from the state of the repo when the run starts. If you push big changes mid-run, the result may need a follow-up pass — easiest is to kick it off at a natural pause. After it completes Review the branch, test locally, merge. See "Review and verify what globalize.now pushed" for a five-minute checklist. Future runs only process what changed, so they're much faster.

The run finished — how do I check what it changed?

The run is complete and globalize.now pushed the results to your repo. Here's how to review and verify before you call it done. Where the changes land Everything arrives on a globalize branch in your repo, for you to review and merge like any other change. Nothing lands on your default branch without you. What you should see /messages (or /locales — depends on your i18n library) en.json ← your source strings, all extracted es.json ← translated de.json ← translated fr.json ← translated Plus modified component files (hardcoded strings replaced with t("checkout.submit")-style calls), the i18n provider wrapped around your app entry, and a new library config. You may also see the globalize skill files added — plain-text instructions that set up your coding agent to work with globalize. They're expected, not junk. If you don't see any of this, check the job status in the app — see "Translation job errors and failures". A five-minute review before you merge 1. Open the source locale file — the values should read like your actual UI text, not fragments or garbled output. 2. Spot-check a few components — t("some.key") calls where inline text used to be, consistent key naming (checkout.submit_button, not a mix of styles), no leftover hardcoded strings in converted files. 3. Check the language files contain actual translations, and all the languages you selected are present. Run it locally 1. Pull the branch — or ask your coding agent to pull and run the app 2. Start your dev server (npm run dev or your usual command) 3. Switch languages with the switcher and click through a few pages Text should change language and nothing should break. If the switcher is missing or switching crashes the app, chat with us in the app — that usually means the provider wiring needs a fix on our side. If something looks off Don't merge — your default branch is untouched. Fix specific files on the branch, or tell us in chat what looks wrong. If entire strings were missed, see "My translation PR looks wrong: what do I do?". Merge, then test the ongoing loop Merge the branch, then make a small text change and push it: git add . git commit -m "test: trigger translation" git push Within a few minutes you should see a pull request from globalize.now with the new string translated in every language. Merge it — that loop is now your localization process. No further manual steps.

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

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 - What project types, frameworks and file formats are supported? — the full detection list and supported formats. - Branches, pull requests and what triggers a translation job — watched branches, PR translation, manual jobs, budget. - Translation quality — glossary, style guides, translation memory, QA review.

I build with Lovable. How do I set up globalize.now?

Yes, globalize.now works with Lovable. You install one skill, connect the globalize MCP, then ask Lovable to do the rest. Every push after that stays translated. What you need first - A Lovable project connected to GitHub. - A globalize.now account. Free signup includes €5 of starting credit, no card. - Workspace owner or admin in Lovable, needed to add a skill once for the whole workspace. Setup 1. Connect your Lovable project to GitHub. In the Lovable editor, open the + menu in the chat, then GitHub, then Connect project. Skip if it is already connected. 2. Add the lovable-i18n skill from GitHub. In Lovable open Skills, click Add, choose Import from GitHub, and point it at: https://github.com/globalize-now/lovable-i18n Use the repository root, no subdirectory. You do this once per workspace; it is free and does not use credits. 3. Add the globalize MCP. In Lovable open Connectors, then Custom MCP, and add: https://api.globalize.now/mcp Authenticate with an API key. Create or copy one from the MCP tab of your globalize.now dashboard. Lovable connectors use API-key auth, not browser sign-in. 4. Ask Lovable to run it. Paste into the Lovable chat: Use the lovable-i18n skill and the globalize MCP to set up i18n and translate my app. Lovable installs Lingui, scaffolds a PO catalog per locale, wraps your hardcoded strings, and adds a language switcher. The MCP connects your repo and translates. Review the diff and merge. 5. Keep building. Every push opens a translation PR with updated catalogs. Merge it and your app ships translated. There is no separate dashboard step and nothing to do between releases. Building in Cursor or Claude Code instead? Same skills, different install. In the connected repo, run: npx skills add globalize-now/globalize-skills --all Then add the same MCP and ask your agent to set up i18n and translate. Troubleshooting - No Skills page in Lovable? You need workspace owner or admin access. Ask your workspace owner to add the skill once; it then applies to every project. - Import from GitHub fails? Point the import at the repository root (https://github.com/globalize-now/lovable-i18n), not a subdirectory — Lovable only reads a skill from the root. As a fallback, download the repo and upload its SKILL.md directly. - Where is the MCP API key? In your globalize.now dashboard, MCP tab. Generate it there; it is shown once.

What does globalize.now actually do to your code?

Two questions most users have before connecting a repo: what exactly gets changed, and can it break anything? What the scan does (read-only) Connecting your repo triggers a scan: globalize.now reads the codebase to detect your framework, whether an i18n library is already configured, and how much hardcoded text there is. The scan changes nothing — it just decides the path and shows you what it found. What the conversion changes If you approve the preparation step, globalize.now works on a clone of your repo — doing the i18n work and translations in parallel, safely — and makes the i18n groundwork changes: components rewritten to use translation keys instead of hardcoded strings, the right i18n library installed and configured, locale files generated, translations filled in. It also installs the globalize skills — plain-text instructions that set your coding agent up to work with globalize, with no separate install. Will it change your code permanently? No. The result arrives on a globalize branch, not your default branch. You review the full diff like any pull request — inspect every change, run the app locally, and merge only when satisfied. What if something looks wrong? - Don't merge. Your default branch is untouched. - Fix specific files on the branch before merging. - Ask us. Chat is in the app — tell us what looks off. Nothing is force-pushed to your default branch — that's a design constraint, not a promise. What about the ongoing translations? Same model. When you push new text, globalize.now translates it and opens a pull request with updated locale files. You review, you merge. The app never commits directly to your default branch. Setting up from your agent instead? The agent path (skills in Claude Code, Cursor, or Codex) makes the same kind of changes, but locally in your editor on a branch you create — see "App, MCP, CLI, or skills — which one do I need?". The skill files themselves install to your agent's skills directory (.claude/skills/ or .agents/skills/) and never touch your app code. If you ran the in-app conversion, they're already installed.