The Translator Is an Agent Too: How AgentKits Localizes Its Own Docs

A Category Most Open-Source Projects Still Skip

Open-source documentation has quietly stopped being an English-only affair. A recent academic survey of GitHub repositories found that the share carrying non-English documentation grew from 3.7% in January 2015 to 13.0% by May 2025 — more than tripling over a decade in which the English-only default was still the unquestioned norm for most projects. The same period saw multilingual content creep into code itself: over 22% of sampled Java files in 2025 carried non-English comments, and 13% had non-English string literals. Localization has historically paid off for the projects that commit to it — WordPress is the standard example, powering more than 40% of the web in large part because it ships in dozens of languages rather than assuming everyone reads English documentation to get started.

Most small and mid-sized open-source projects still don’t localize, for an unglamorous reason: it’s expensive to keep translations current. A README that changes weekly needs a translation workflow that changes weekly too, and hiring or contracting that out doesn’t scale to a project with a handful of maintainers. AgentKits — our open-source, MIT-licensed toolkit of AI agent kits, with 20 agents, 77 commands, and 28 skills in the shipped Marketing Kit — solved that constraint in a way worth describing in some detail: it built a tool that translates its own documentation with an agent, and then published the tool itself as a separate open-source package.

What’s Actually Running

The tool lives in the repo as scripts/translate-readme, and it’s real, working Node.js code built directly on @anthropic-ai/claude-agent-sdk’s streaming query() API — not a wrapper around a conventional translation API. A handful of engineering choices in that script are worth calling out specifically, because they’re the difference between “a script that calls an LLM” and a pipeline someone can actually run unattended, repeatedly, without it becoming a cost or correctness problem.

First, caching. Every source document gets SHA-256 content-hashed, and the hash is checked against a .translation-cache.json file before any translation runs. If the English source hasn’t changed since the last run, the cached translation is reused and no API call happens. This matters more than it sounds: without it, every CI run or maintenance pass would re-translate every document in every language from scratch, burning tokens on content that didn’t change.

Second, concurrency. Translation jobs run in parallel, capped at Math.min(languages.length, 10) concurrent requests — enough to make a ten-language run finish in roughly the time of one language’s translation, without firing an unbounded number of simultaneous API calls.

Third, cost is tracked, not assumed. The script reads total_cost_usd directly off the SDK’s own result message for each translation job, and supports an optional maxBudgetUsd cutoff that stops the run rather than translating past a spending limit. That’s a meaningfully different posture from treating an LLM call as a fixed-cost API request the way a traditional machine-translation API bills — flat per-character pricing doesn’t need a budget cutoff; a model call that can vary in cost per document does.

Fourth, and probably the most important detail for anyone translating technical documentation specifically: the prompt explicitly instructs the model not to touch code fences, file paths, or slash commands like /training:start-0-0. A generic translation API has no concept of “this substring is a command the reader is supposed to type verbatim” — it will happily translate a code comment inside a fence or mangle a CLI flag. An LLM given plain-language instructions about what counts as code versus prose can honor that distinction directly, which is exactly the kind of instruction-following that makes LLM translation a different category of tool from classic neural machine translation for developer content.

The Same Tool, Reused for a 23-Module Course

The translate-readme tool isn’t a one-off script for a single file. The same underlying pipeline (packaged separately as scripts/translate-training) generates full localized command trees for AgentKits’ 23-module marketing training course — the interactive curriculum that walks a learner through campaign strategy using AgentKits’ own product as the running case study. The repository’s command tree shows the result: ten fully generated language variants of the training path (commands/training-ar, -de, -es, -fr, -ja, -ko, -pt-br, -ru, -vi, -zh), each a complete parallel copy of all 23 modules, not a partial or summarized version.

The language selection itself isn’t arbitrary — it’s staged, and the reasoning is written directly into the tool’s own source as comments grouping target languages into rollout tiers: a “Tier 1 — no-brainers” group (Chinese, Japanese, Brazilian Portuguese, Korean, Spanish, German, French) covering the largest and most commercially obvious developer markets first, a “Tier 2 — strong tech scenes” group (Hebrew, Arabic, Russian, Polish, Czech, Dutch, Turkish, Ukrainian), and further tiers beyond that. It’s a small detail, but it’s a real one: the rollout wasn’t “translate into every language we can think of,” it was an explicit, prioritized bet on where a marketing-agent toolkit’s next users are most likely to come from.

Why an LLM, Not a Translation API

It would have been possible to wire the same pipeline to a conventional neural machine translation API instead of an LLM, and it’s worth being specific about why that would have been the wrong trade for this particular content. Benchmark data from 2026 shows LLMs scoring 8-15% higher on COMET evaluations than traditional NMT engines specifically on complex, terminology-heavy content — and in the WMT24 shared task, LLM-based systems won 9 of 11 language pairs against specialized neural MT systems built for exactly that job. The gap shows up because LLMs can read broader document context, hold a glossary and tone instruction across an entire file, and follow plain-language formatting rules — precisely the “don’t touch this slash command” instruction AgentKits’ own prompt relies on.

The cost story cuts the other way, and it’s worth naming honestly rather than only citing the flattering number. Traditional NMT APIs like Microsoft Translator price around $10 per million characters — a genuinely cheap, predictable unit cost at high volume. LLM APIs bill per token instead of per character, and pricing varies enormously by model tier: a cost-efficient option like DeepSeek V3 runs roughly $0.27 per million input tokens, while a premium model built for nuance costs meaningfully more. For a project translating a whole training curriculum into ten languages on every meaningful content change, that’s exactly the trade-off the maxBudgetUsd cutoff and SHA-256 caching in AgentKits’ pipeline are built to manage — pay the premium for context-aware, instruction-following translation, but bound how much of it happens and skip work that’s already been done.

The Part Worth Noticing

AgentKits ships a Marketing Kit built around AI agents that plan campaigns, write copy, and optimize funnels for other companies’ products. The tool it uses to translate its own README and its own training curriculum into ten languages is, itself, an agent — built on the same SDK, following the same “give a model plain-language instructions and let it reason over context” pattern the rest of the kit is sold on. That’s not a coincidence worth glossing over: a project whose product pitch is “let an agent do this work reliably” choosing to run its own documentation pipeline the exact same way is a more concrete form of confidence than a case study could be, and it’s checkable — the translated docs and the tool that produced them are both sitting in the same public repo.