Crowdin just shipped an i18n agent skill. We've had one since March.

Crowdin released an agent skill in August that takes a JavaScript app from hardcoded strings to a connected Crowdin project, and last week they published a walkthrough of it. We are glad they did. globalize.now is AI-powered localization infrastructure, we have had agent skills doing this job since March, and a company founded in 2008 arriving at the same design is the clearest sign yet that the problem is real.

It is also a good moment to compare the two approaches honestly, because they end in very different places. Theirs ends with your files inside a translation management system that you then have to operate. Ours ends with a pull request that already contains the translations.

What did Crowdin actually ship?

Four new agent skills, a rewritten CLI, and a plugin that bundles them with their MCP server. The August changelog, published on 4 September, lists i18n-setup, glossary-generation, crowdin-cli and github-action. They join the context and API-query skills Crowdin had been adding to crowdin/skills since February.

CLI 5.0 is the best engineering in the release. It moved from Java to TypeScript, ships as a single binary, and prints JSON for an agent to read. Crowdin calls it "Built for AI agents", which is fair.

The headline is i18n-setup. On 16 September Crowdin posted a seven-minute video of it running in Claude Code against a small sample site.

Who shipped what first?

It depends what you count, so we read the commit history of all three repositories. Lingui published the first agent skills, in January. The first skill that sets up i18n in a repo and wraps the hardcoded strings was ours, on 29 March.

Credit where it is due: Crowdin's MCP server predates our company, and their skills repository is five weeks older than ours. Those early Crowdin skills taught an agent to write translator context. Touching the application code came later. Our setup and string-wrapping skills date from 29 March and the orchestrator that runs the whole journey from 5 April. Crowdin's equivalent landed on 28 August, two weeks after Lingui added the setup skill it depends on, with the same skeleton of detect, decide, set up and wrap.

We take that as a compliment to the design, not as evidence of copying. It is the obvious shape once you accept the premise, and the video opens with the premise: "The product may be ready for production, but it doesn't mean it's ready for translation." We made the same argument in our first post in March.

Other vendors outside these three have put i18n behind an agent too, so we are not claiming a world first.

What does Crowdin's i18n-setup skill do?

It runs seven phases inside your own coding agent and keeps a resumable checklist in your repo. The skill file is well organised, and the walkthrough matches it.

1. Detect. Scan the repo for the framework and any existing i18n library.
2. Decide. Ask which languages you want and whether to run guided or unguided, then write a plan.md.
3. Setup. Install and configure Lingui. If you already have a library, it keeps yours.
4. Wrap. Mark user-facing strings and extract PO files.
5. Connect. Create a Crowdin project with the CLI and upload the files. This needs your Crowdin token.
6. Context. Read the code around each string and write a note for translators. Suggest a starter glossary.
7. CI. Install a GitHub workflow so new strings go to Crowdin and translations come back.

One detail the video skips: Crowdin's skill does not do phases 3 and 4 itself. Its manifest hands them to Lingui's own skills, which you install as a second plugin. Crowdin's own work starts at phase 5.

Some of this is thoughtful. The agent never sees your token value, and the skill stops to ask when something is ambiguous. The limits are in the file too. Fresh installs are Lingui only and the scope is JavaScript and TypeScript. Projects already on i18next, next-intl or vue-i18n get a connect-only path. It refuses Create React App, and it will not migrate you between libraries.

What does it leave to you?

Translation, and everything required to make translation happen. Read the seven phases again: not one of them produces a translated string.

This is deliberate. The skill file lists auto-translate as an add-on that is off by default, with the instruction to "never machine-translate a fresh project unasked". If you opt in, the agent may only apply translation memory, and a new project has none. Machine or AI translation is allowed only when an engine or prompt already exists in your Crowdin account.

Once the skill finishes you own a Crowdin project, and you need to know Crowdin. To get AI translations you open your profile, enable a provider with your own API key or by adding funds to a Crowdin balance, and create a prompt. Then you run pre-translation from the editor, or from the CLI using the prompt ID you just created, or you turn on the per-project auto-translate setting. After that there are approvals to think about, then a build, then a download.

All of it can be automated by someone who already knows where those settings live. That is the catch. The agent did the part a developer understands, then handed over a product built for localization managers. In Crowdin's own walkthrough, the presenter still gets his Chinese strings by opening the editor, clicking machine translation, and pulling the result back with the CLI.

Crowdin's MCP server does not close the gap. Its documented tool sets work inside an existing project, and we found no pre-translation or project-creation tool in the docs. That is a documentation read, not a test of every tool.

How is globalize.now different?

The i18n conversion and the translation are the same job, and the result is a pull request. There is no project to configure on the side, because there is no side.

The default path is in the app. You sign up, connect GitHub or GitLab, and pick a repo. A scan decides what happens next. If there is no i18n yet, we add the groundwork. If you already use next-intl, react-i18next, i18next or Lingui, we connect to what you have and leave your file structure alone. You approve the plan. The conversion and the translations then run in parallel on a clone of your repo, in our cloud, and land on their own branch. Nothing touches your default branch until you merge.

That first conversion happens once. From then on, when you push new source strings, a push job translates them and opens a pull request with the result.

If you would rather stay in your editor, the same job starts from a prompt. Our Claude Code integration and the skills behind it connect the repo for you. We have written before about why we ship a skill instead of an SDK.

Crowdin's seven phases run on your agent, so they spend your tokens. Our conversion runs on our side. And someone who built their app in Lovable and has never opened a terminal can finish our flow, which is not true of anything that starts with exporting an environment variable.

It is not instant. Small repos take minutes and a large codebase can take an hour or more. You still read a plan and you still review a PR, as you should.

Crowdin i18n-setup vs globalize.now, step by step

When should you pick Crowdin instead?

When people translate your product. If you have in-house linguists, an agency, or a community of volunteers, you need translation memory, glossaries, an in-context editor, review steps and vendor handling. That is a translation management system, Crowdin has been building one since 2008, and we are not trying to be one.

Crowdin also handles formats we do not support today, including XLIFF, ARB, .xcstrings and Android XML, and its skill can connect a vue-i18n project. If your main product is a native mobile app, check that before anything else.

The full comparison page goes deeper on pricing models and team fit.

Why does it matter that an incumbent shipped this?

Because it settles an argument. Lingui, Crowdin and we now agree that the agent should prepare the code, that the developer should approve a plan instead of doing the work, and that this belongs in the editor where the app is being written.

Where we still disagree is what comes after. Crowdin's answer is a better on-ramp to the dashboard. Ours is that most teams shipping with Cursor, Claude Code or Lovable do not want a dashboard. They want their app in German by the end of the day and a PR every time they add a button.

The useful question to ask any vendor with an agent story is simple: when the agent is done, where do I have to go next? If the answer is a new product to learn, the agent was a front door. If the answer is your pull requests tab, it was the whole house.

Try it on your own repo

Run the test Crowdin ran: take a small app with hardcoded strings and see where you are an hour later. Connect a repository, approve the plan, read the pull request. The trial needs no card. Pricing is here if you want it first.