Why in-repo i18n makes agentic AI a better translation partner

I recently worked on cleaning up a Next.js site’s localization and discovered how much smoother things get when translations live in the repository itself (for example in content/en/*.json and content/nl/*.json). If you give an agentic AI access to the codebase, it’s not just translating strings - it can understand how those strings are used, make the right code changes, and verify the result.

Why this works so well for small projects

• Practical and fast: For solo developers and small teams it’s often quicker to keep translations next to the code. An AI can open a PR that updates text and fixes the handful of code spots that need changing.
• Real context: The agent sees the component, the props, and the types. That means it can avoid awkward translations by checking how a string is rendered, and it can rename keys or remove unused fallbacks safely.
• Safe edits: The agent can run type checks and linters, correct small issues (like metadata typing or unused imports), and only submit changes that pass automated checks.
• One-step fixes: Want to replace hardcoded labels across the app? The agent can add translation keys, update components, and validate the build in one go - no manual export/import dance.
• Privacy & ownership: The translation data stays inside your repo - no external service or secret sync job to manage.

When this isn’t the right fit

This approach shines for small-to-medium projects. For large enterprise environments, where translations are managed by dedicated localization teams, you often need workflow features that hosted platforms provide: role-based access, human translation UIs, translation memory, and reviewer workflows. In those cases a hosted i18n solution (or a hybrid setup) is usually the better option.

A sensible middle ground

Many teams find a hybrid approach works best: keep core UI strings in-repo so an agent can make fast, context-aware edits, and use translation tools for large-scale localization by professional translators. CI checks can bridge the two, ensuring nothing breaks when content is updated.

Example from this repo: I had the agent replace hardcoded UI strings, remove unnecessary fallbacks, and fix a couple of TypeScript metadata warnings - all in a single PR. The changes were small, reviewed quickly, and deployed without surprises.