Home Using globalize.now

Using globalize.now

Branches and triggers, translation quality, teams, existing i18n, and the agent paths (skills, MCP, CLI).
globalize.now
By globalize.now
• 11 articles

Connect a GitHub repo and sync translations on every push

Once your locale files live in a GitHub repo, Globalize can keep them translated automatically. When you push new source text, Globalize opens a pull request with the translations already filled in. You review and merge — nothing is pushed to your main branch directly. This guide covers connecting a repo through an AI agent using the MCP server. Before you start - Install the Globalize GitHub App on the account or organisation that owns the repo. If it isn't installed yet, the agent can start the install and hand you a link to approve in your browser. - Push your latest code first. Globalize reads the repository from GitHub, so any locale files that only exist locally won't be seen. Steps 1. Find your installation. The agent lists your GitHub App installations and picks the one that owns your repo. 2. Detect the repo. The agent scans it and reports what it found — your framework, the locale file pattern (for example messages/{locale}.json), the file format, and your source and target languages. This confirms Globalize will read the right files. 3. Connect it. The agent links the repo to your project and registers a webhook. Your existing translations can be imported as final so they aren't re-translated. 4. Push new text. Add a new string to your source locale file and push to your connected branch. 5. Review the PR. Within about a minute, Globalize opens a branch like globalize/translations-main with a pull request adding the new keys to each target language. Merge when you're happy. Good to know - The pull request is scoped to what changed. New keys get translated; your reviewed translations are left alone. - Locale files always live in your repo. You own them, and every change goes through a PR you approve. - If a translation reads too formal or too casual for your brand, set a per-language style guide (for example, "use informal address") so future translations match your voice. Using GitLab instead? The same flow works with a GitLab repository: connect it from the app, pick the watched branches, and translations arrive as merge requests. Azure DevOps is on the roadmap.

Last updated on Sep 16, 2026

Branches, pull requests and what triggers a translation job

What triggers a job Pushes to watched branches. In Project → Settings → Repository → Watched branches, pick the branches whose new or changed source strings should be translated automatically. Usually that is main, but you can watch several. A push with string changes starts a job; a push without any doesn't. Pull requests (optional). Turn on Translate pull requests and new strings in a PR are translated and committed straight onto the PR branch, so the translations ship with the feature. Skip draft pull requests leaves drafts alone until they're marked ready. Manual jobs. From the project dashboard, run a translation job on any branch and choose whether to open a pull request or push the translations directly. What the pull request looks like One PR per job, containing only your locale files, with only the keys that are new or changed in this job. Existing translations you have reviewed are left untouched. Nothing is pushed to your default branch without a PR unless you chose direct push on a manual job. Reviewing before merge Review the PR as you would any other. Change a translation in the diff if you disagree with it — your edit becomes the approved version and feeds the translation memory (see Translation quality). Merge when you're happy. Job status in the app moves through pending → processing → review → completed; a failed job shows its error and can be retried. Notifications and limits Project → Settings → Notifications: a webhook URL and/or email recipients for job completed, job failed, QA issues and delivery failed. Project → Settings → Budget: an optional monthly spending limit in EUR. Jobs are rejected, not silently run, once the limit is reached. Git hosts GitHub and GitLab are supported: connect the repository, and pushes to watched branches open pull requests (GitHub) or merge requests (GitLab) the same way. Azure DevOps is on the roadmap — tell us at support@globalize.now if you need it and we'll let you know when it lands.

Last updated on Sep 16, 2026

How do I control tone, terms and quality? (glossary, style guides, translation memory, QA)

globalize.now translates with large language models and reviews every translation with a second AI pass. Four tools shape the result, and all of them live in your project. Glossary Project → Glossary. Add a source term, its required translation, and the languages it applies to. Glossary terms are protected during translation, so product names, feature names and legal wording stay exactly as you decided. You can import a glossary in bulk instead of typing entries. Style guides Project → Style Guides. One per target language: tone, formality (for example du vs Sie, tu vs usted), terminology preferences, what to leave in English. If a language has none yet, the dashboard offers to draft one from your own source content in one click; edit it and save. Translation memory Project → Translation Memory. Every approved translation is stored. When the same source string appears again — another push, another component, another project file — the stored translation is reused and not billed. Translations you edit by hand and push back are treated as approved and win over ours. QA review Every job runs a quality-review pass on each target language after translation. It checks the translation against the source for meaning, placeholders and variables, glossary compliance and style-guide fit, and flags anything that doesn't pass. Each language's results are summarised on the project dashboard in three buckets — good, passable, and needs attention — and you can turn on a QA issues notification (webhook or email) in project settings. Editing translations after they're generated Translations arrive in a pull request that changes only your locale files. Edit them there like any other code change, or later in your repository. To make your edits authoritative, set Existing translations → Every string, on every push in project settings: your files win, and the translation memory is updated from them. Which models Translation and review currently run on Anthropic's Claude models. We choose the model for quality and cost; per-job model selection isn't available today. Text is sent to the model provider for translation only and is not used to train models. How good is it? Better than phrase-based machine translation because the model sees the whole string, its placeholders and your glossary and style guide at once; cheaper and faster than a human translator; not a replacement for a native review where the stakes demand one. The QA pass exists to make the cases that need a human visible rather than silent.

Last updated on Sep 16, 2026

What project types, frameworks and file formats are supported?

Supported frameworks globalize.now works with React-based web apps. Current first-class support: | Framework | Status | |---|---| | Next.js (App Router) | ✅ Fully supported | | Next.js (Pages Router) | ✅ Fully supported | | React + Vite | ✅ Fully supported | | React + Create React App | ✅ Supported | | TanStack Router / Start | ✅ Supported | 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. | Project type | Code setup | Locale files kept translated | |---|---|---| | iOS / macOS | ❌ | ✅ .xcstrings | | Android | ❌ | ✅ strings.xml | | Flutter | ❌ | ✅ .arb | | Browser extensions | ❌ | ✅ Chrome messages.json, WXT | | Vue / Svelte / Angular | ❌ Not yet | ✅ if the files are JSON, .po or XLIFF | | Blog posts, docs and other Markdown | — | 🟡 Rolling out now — ask support to switch it on | | WordPress / HubSpot CMS | ❌ Out of scope | ❌ | | Non-UI backend files | ❌ Skipped automatically | — | 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: | Library | Output format | |---|---| | next-intl | JSON under /messages/ | | i18next | JSON under /public/locales/ | | LinguiJS | .po or JSON via Lingui CLI | When it keeps existing locale files translated, these formats are supported: | Format | Typical use | |---|---| | JSON, flat or nested | next-intl, i18next, most web apps | | Gettext .po | Lingui, many backends | | XLIFF 1.2 and 2.x (.xlf, .xliff) | Angular, exports from other translation tools | | ARB (.arb) | Flutter | | Apple String Catalog (.xcstrings) | iOS and macOS | | Android strings.xml | Android | | YAML (.yml, .yaml) | Rails | | Chrome messages.json, WXT i18n | Browser extensions | | Markdown, HTML | Long-form content (rolling out, see above) | 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.

Last updated on Sep 17, 2026

Where do my translations live, and do you store them?

In your repo. globalize.now writes locale files and commits them to a branch of your GitHub or GitLab repository, like any other code change. You own the files. What the output looks like After the first run your repo contains a locale directory with one file per language: /locales en.json es.json de.json fr.json Or, with next-intl: /messages en.json es.json The location and format follow your i18n library, and the locale path patterns in project settings tell us where to look if your layout is non-standard. How updates work When you push new or changed UI strings to a watched branch, globalize.now translates only those strings and opens a pull request (merge request on GitLab) containing only the locale files that changed. Review it, edit it, merge it like any other PR. See Branches, pull requests and what triggers a translation job for the triggers. What if I merge my code before the translation PR? Nothing breaks. Your app falls back to the source language for the missing keys. globalize.now keeps watching the branch and the missing translations arrive in the next PR. The cleanest workflow is still to merge the translation PR alongside the feature, or turn on Translate pull requests so translations land on the feature branch itself. Can I edit translations myself? Yes, in two places: - In the PR. Change a translation in the diff before merging. Your edit becomes the approved version and is stored in the translation memory. - In the repo. Locale files are plain JSON or .po; edit them with any editor and push. By default we only touch strings we haven't seen before, so your edits stay. To make your files authoritative on every push, set Project → Settings → Existing translations → Every string, on every push. Do globalize.now servers store my translations? Two things are stored on our side: the translation memory (every approved source/target pair for your project, so repeated strings are reused and not billed — visible under Project → Translation Memory) and job history. Your locale files in the repo remain the source of truth; if the two ever disagree, the Existing translations setting above decides which wins. For translation jobs, source text is sent to the model provider (currently Anthropic's Claude models) for translation only and is not used to train models. Where our servers are, which providers process your text and code, and how to delete your data: Security and data. No vendor lock-in Your locale files are standard JSON or .po. If you stop using globalize.now, everything stays in your repo and keeps working exactly as it does today. Switch to any other tool or manage the files by hand — nothing is locked to our platform.

Last updated on Sep 17, 2026

How do I add or remove a language?

You don't need to re-run the setup. Adding a language is two steps: add it in your project, then run a job. Step 1 — Add the language 1. Log in to globalize.now 2. Open your project → Languages 3. Click Add language, pick the target language, save If you'd rather commit a new locale file to the repo and have it picked up, turn on Auto-discover target locales in project settings. Step 2 — Run the first translation Either run a manual job from the project dashboard on the branch you want (choose whether it opens a pull request or pushes directly), or just push your next change to a watched branch. Either way globalize.now sees the new target language, translates the full back-catalogue of existing strings for it, and opens a PR with the new locale file. Expect a few minutes for a typical app. Removing a language Project → Languages, remove it, save. The existing locale file stays in your repo — we never delete files from your codebase. Delete it yourself if you want it gone. How many languages can I have? No hard limit. Each language is translated and quality-reviewed separately, so each one you add uses translation credit when new strings arrive — and the first run for a new language translates everything that already exists, which is the largest single job you'll see for it. As a guide, translation costs about €0.10 per 1,000 translated words per language, review included. See How is billing calculated? for what your plan includes.

Last updated on Sep 16, 2026

How globalize.now fits into your stack

Two questions in one: what's the difference between globalize.now and your coding agent, and do you need both globalize.now and an i18n library? globalize.now vs your coding agent They work together. Your agent does the coding work. globalize.now gives it the instructions and handles the infrastructure. This works the same whether you're using Claude Code, Cursor, or Codex. Your AI coding agent reads your files, rewrites your components, generates locale files, and makes changes to your repo. Without globalize.now's skills, it improvises, and produces inconsistent key names, misses strings, or builds an architecture that breaks when you add new features. globalize.now does two things: 1. Installs skill files into your agent, the playbook it follows (which i18n library, how to name keys, how to handle RTL, plurals, and dynamic strings, how to structure locale files) 2. Runs translation infrastructure, the server-side jobs that translate your strings on every push and open PRs with updated locale files | Step | Who does it | | --- | --- | | npx skills add --all globalize-now/globalize-skills | globalize.now installs the skills | | Set up i18n for my project | the globalize-guide skill inspects your stack, plans, installs the library, wraps strings, generates locale files | | Connect globalize.now to my repo | the globalize-now-cli-setup skill connects your GitHub or GitLab repo | | Auto-translate on push | globalize.now's cloud infrastructure | | PR with updated locale files | globalize.now opens it, you review and merge | Do you need both globalize.now and an i18n library? Yes. They do different jobs. globalize.now handles infrastructure: scans your repo, generates translation keys and locale files, syncs on every Git push, keeps your locale files current. An i18n runtime library (next-intl, Lingui, react-i18next, i18next) handles the runtime: loads the right locale file for the current user, renders translated strings in the browser or server, handles pluralization and ICU message formatting, manages locale switching. globalize.now produces the locale files. The i18n library consumes them. Neither replaces the other. The setup step auto-detects your framework and installs the right library, you don't need to choose or configure it manually. | Framework | Library installed | | --- | --- | | Next.js (App Router) | next-intl | | Next.js (Pages Router) | i18next / react-i18next | | React + Vite / CRA | Lingui |

Last updated on Sep 16, 2026

App, MCP, CLI, or skills — which one do I need?

Globalize gives you a few ways to reach the same backend. Most people now only need the first one. Here's how they fit together. The app — the default path Sign up, connect your GitHub or GitLab repo, done. The scan detects whether your codebase needs i18n preparation, the conversion does the code changes in the cloud, translations run automatically, and results are pushed to your repo. You never install anything — the conversion even installs the agent skills for you, so if you later want to drive globalize from your editor, they're already in place. If you're not sure which path you want, this is the one — see "How globalize.now works — overview". The skills — the agent path for changing code locally npx skills add globalize-now/globalize-skills installs a playbook into your coding agent (Claude Code, Cursor, Codex). If you used the in-app conversion, the skills are already installed — no npx needed. The agent then does the codebase work locally in your editor: detects your framework, installs the right i18n library, turns hardcoded text into translation keys. Choose this when you want the conversion to happen on your machine, under your eyes, with your agent driving. If your agent is already connected to the MCP server, the install-skills prompt installs the whole set in one step — no manual npx needed. The MCP server — drive Globalize from inside your agent Connects an AI agent to your Globalize account: create projects, add languages, translate locale files, connect your repo, manage glossary and style guides — all from chat, without leaving your editor. It works on locale files and settings; it doesn't edit source code. The CLI — the command layer underneath The globalize CLI is the surface the skills call for account, project, and repo setup. You rarely run it directly; it's there for scripted, non-interactive control. The short version Want the result with the least setup? Use the app. Want the conversion to run locally through your own agent? Skills first, then MCP/CLI. Either way, the ongoing loop is identical: push new text, get a translation pull request.

Last updated on Sep 16, 2026

Connect an AI agent with the Globalize MCP server

The Globalize MCP server lets an AI agent — Claude, Claude Code, Cursor, or any MCP-compatible client — work with your localization directly: create projects, add languages, translate files, and connect a GitHub repo, all from inside the tool you already use. A connected agent acts on your behalf, with your own permissions. The server endpoint is: https://api.globalize.now/mcp Pick your setup Claude.ai, ChatGPT, or any client with OAuth 1. Add Globalize as a custom connector using the URL above. 2. Sign in with your Globalize account when the client prompts you. No API key needed. 3. Tool calls run as you, in the organisation you last used in the dashboard. Claude Code Run this in your terminal, then run /mcp inside Claude Code and sign in through your browser: claude mcp add --transport http globalize https://api.globalize.now/mcp Cursor Add this to ~/.cursor/mcp.json. Cursor prompts you to sign in on first use: { "mcpServers": { "globalize": { "url": "https://api.globalize.now/mcp" } } } Any other MCP client Generate an API key on the MCP page in your dashboard (it's shown once), then configure a Streamable HTTP transport pointed at the endpoint with the header Authorization: Bearer <your key>. What the agent can do once connected - Set up projects — create a project, add or remove target languages, set project-wide context. - Connect your repository — link a GitHub repo, detect its framework and locale file patterns, and keep translations in sync on every push. - Translate files — hand the agent a locale file (JSON, ARB, PO, XLIFF, YAML, Android XML, or iOS .xcstrings) and get the translated versions back. - Keep quality consistent — manage a glossary and per-language style guides. What it does not do The MCP server does not internationalize your source code. It works on locale files, not your components. To turn hardcoded strings into translation keys, use the Globalize skills in your coding agent. If your agent is connected to the MCP, install them in one step by running the install-skills prompt (a slash command) instead of running npx skills add globalize-now/globalize-skills yourself. See "App, MCP, CLI, or skills — which one do I need?" Revoking access Remove the connector in your client, and revoke any API key from Settings → Manage keys in the dashboard.

Last updated on Sep 16, 2026

Security and data: where your code goes and who processes it

The short version: your translations live in your repo, our servers are in Germany, AI providers may not train on your text or code, and support deletes your organisation's data within 3 business days of a request. Where your data is stored - Your translations and locale files live in your own GitHub or GitLab repository. You own them. - On our side we keep your projects, glossary, style guides, translation memory and job history on Hetzner servers in Falkenstein, Germany. - The working data of each translation job (the source strings, uploaded files and detailed QA findings) is deleted 30 days after the job finishes. The job record, its cost and the translation memory stay. What happens to your source code - Translation jobs read your locale files. They don't need your application code. - The one-time code setup (the in-app conversion) clones your repository into an isolated container. The container is destroyed automatically when the run ends. The changes arrive on a branch in your repo, and we keep the diff and the run log so you can review what was changed. - Repository access is limited to the repositories you choose when you install the GitHub or GitLab integration. Which AI providers see your text - Translation and quality review go directly to Anthropic's Claude models through Anthropic's API. Anthropic does not train on this data. - The code setup runs DeepSeek models (a fast model, escalating to a larger one where a file needs it) through OpenRouter. Every request is sent with data collection denied and zero data retention enforced, so your code can't be stored or used for training. We don't sell your data or share it for advertising. Subprocessors | Provider | What we use it for | What it sees | | --- | --- | --- | | Hetzner (Germany) | Hosting and database | All service data | | Cloudflare | DNS and CDN, file storage, the code-setup containers | Uploaded files; your code during a setup run | | Anthropic | Translation and quality review | Source and translated text | | OpenRouter, and the inference provider it routes to | AI model for the code setup | Your code during a setup run, with zero data retention | | GitHub / GitLab | Repository access | The repositories you connect | | Clerk | Sign-in | Name and email | | Stripe | Billing | Billing details | | Resend | Account emails | Email address | | Chatwoot | Support chat | Support conversations and account details | | OpenPanel | Product analytics | Usage events | | OpenAI, Google (Gemini), DeepL | Configured as alternative translation providers, not used today | Nothing today | We'll update this list before we start using a new provider for customer content. GDPR globalize.now SIA is an EU company, registered in Riga, Latvia, and is subject to the GDPR. Our servers are in Germany. - Data processing agreement: we don't offer a signed DPA yet. - SOC 2: on our roadmap for Q1 2027. - Questions about how we handle data: support@globalize.now. Deleting your data Ask us in the support chat in the app, or email support@globalize.now, from an admin of your organisation, and we delete your organisation's data within 3 business days. You can also delete your own user account from the account page in the app; to remove the organisation's projects and translation data as well, ask support. Your locale files stay in your repository either way. We never delete files from your codebase.

Last updated on Sep 17, 2026