What happens when an AI agent internationalizes a real monorepo?

It extracted 28 UI string candidates, rewrote 41 translation entries across multiple files, configured middleware and routing, and generated locale files for 5 target languages. Setup, conversion, and translation took about 90 minutes end-to-end. globalize.now is AI-powered localization infrastructure, and we ran it on a production monorepo to see what would actually happen. No curated demo. No safety net. Just a real codebase with real complexity.

The codebase belonged to a localization industry veteran who spent over a decade as an architect at one of the leading translation management platforms.

What was in the monorepo?

This was not a tutorial project. The monorepo contained a Next.js web application, an Android app, MCP servers, and documentation rendered by a third-party service. The developer uses Claude Code daily, builds with AI tooling end-to-end, and had assembled the entire stack in three months.

The target was the Next.js frontend. The Android app, the MCP servers, the docs site built on Mintlify. None of that should be touched. The question was whether an AI agent could figure that out without being told explicitly.

It could. The agent scanned the full repo and focused on the Next.js application. No manual scoping was needed in practice, though the developer noted he would have appreciated the ability to say "only convert /apps/web" for peace of mind. That is a fair point and something worth adding. But it did not block the conversion.

How did configuration work?

The developer chose guided mode to understand the process. Configuration covered five decisions: package manager (NPM, despite a legacy PNPM lockfile also existing), catalog format (PO/GetText, recommended for comment support), setup mode (guided), source language (English), and target languages (Spanish, Italian, Hungarian, Czech, Slovak).

One observation worth noting: the catalog format question caused hesitation even for someone with deep localization expertise. His reaction was direct. He did not think the choice mattered enough to ask the user about it. Automate it.

Routing strategy was path-based. No domain-based routing since the developer did not own extra domains. The app uses OAuth-based authentication, so login flows remained in English by design. The agent handled this correctly.

What does the conversion step actually do?

This is the part that matters. The agent identified 28 UI string candidates across the Next.js app and processed 41 translation entries. It reorganized files, updated middleware, modified component imports, and generated PO locale files for all 5 target languages.

The conversion step alone took approximately 30 minutes. Add setup and configuration before it, and the developer completing the translation connection independently afterward, and the full end-to-end was closer to 90 minutes. That is not instant. For context, a simple app with a handful of pages completes the full flow in under 15 minutes. A complex app with dozens of translatable surfaces takes longer. The time scales with the number of strings, not the size of the repo.

The developer watched the conversion step run and said this: the string extraction and code rewriting is the heavy lifting. This is the work developers dread. At his previous company, a leading TMS, the translation files in the repo were just the tip of the iceberg. The preparation and internationalization work was the real pain. And the AI agent handled exactly that piece.

This tracks with what we hear from every developer who has gone through i18n manually. Nobody complains about the translations. They complain about touching 40 files to wrap strings in t() calls, generating keys that make sense, restructuring imports, and configuring middleware. That is the work globalize.now automates.

Did it actually work end-to-end?

Yes. After the live session ended, the developer completed the remaining steps independently. He published the globalize.now Git branch, connected the app to the web platform, set monitoring to the globalize.now branch, and confirmed that files were uploaded and translated correctly.

His assessment of Czech translation quality: close to perfect. This is from someone who spent his career evaluating localization output professionally. That is not a generic thumbs-up. That is a domain expert confirming production-viable quality on a non-trivial language pair.

He flagged two issues in the web app after completing the flow independently. First, a re-scan of the repo showed "no i18n files detected" even though the translation job was actually running in the background. A misleading UI state, not a real failure. Second, the translation job started without explicit consent. Any action that costs credits should require confirmation. Both are valid UX issues being addressed.

What went wrong?

Things broke. This was a real test, so we are going to be honest about it.

The installation command (npx globalize-skills) failed on Windows PowerShell. This was the first time the tool had been tested on Windows. The skills had to be sent as a zip file via Swiss Transfer after Google blocked the email attachment. Total setup friction: about 15 minutes before the actual flow started.

An ES modules vs. CommonJS conflict surfaced mid-conversion. The project uses CommonJS, and the agent's output assumed ES modules in one spot. Not a blocker, but something that should be detected during setup and handled proactively.

At the end of the session, connecting the GitHub repository in the globalize.now web app returned a blank page. The developer was using Opera. No login screen, no error, no content. The session ended before it was resolved.

Three bugs. All real. All fixed or in progress.

Why is string extraction the real bottleneck?

Most i18n content focuses on translation quality, framework configuration, or TMS feature comparisons. That misses where developers actually lose time.

Adding internationalization to an existing codebase means scanning every component for hardcoded strings, deciding which strings are translatable, generating meaningful translation keys, wrapping each string in the appropriate t() or <Trans> call, updating imports across the file tree, creating the initial locale files, and configuring routing middleware. For a monorepo, add the complexity of figuring out which parts of the codebase even need i18n.

This is tedious, error-prone, and exactly the kind of work AI agents are good at. The developer who watched it happen put it clearly: from the developer's perspective, this is the heavy lifting. This is a big relief. Vibe coders building with AI tools can now skip the worst part of going international entirely.

What did we learn about monorepo scoping?

The agent handled monorepo scoping implicitly. It focused on the Next.js web app and ignored the Android code, MCP servers, and Mintlify docs without being told to. That is the correct behavior for most cases.

But implicit scoping is not the same as explicit scoping. The developer wanted the ability to say "convert only my Next.js app" as a configuration step. In a monorepo with multiple web frontends, say a customer-facing app and an admin dashboard, you would want precise control over which frontend gets internationalized first.

This is a product gap we are closing. For now, the agent gets it right in practice. Explicit scoping should be a configuration step, especially when the conversion touches dozens of files.

How does this compare to manual i18n setup?

Manual i18n setup on a codebase of this complexity takes days. Not because any single step is hard, but because there are dozens of steps and each one requires attention. Miss a string, and you ship a half-translated page. Get a key name wrong, and you create duplicate entries that haunt you for months. Forget to update middleware, and your locale routing breaks silently.

The AI agent completed the equivalent work in about 90 minutes, end-to-end. The developer, someone who has seen thousands of i18n implementations professionally, called it elegant.

For developers building with AI tools, this changes the calculus on when to add languages. If i18n setup takes a week, you postpone it until you have proven product-market fit. If it takes 90 minutes, you can ship multilingual from day one.

globalize.now handles this. Run npx skills add globalize-now/globalize-skills in your project or see how it works at globalize.now.