मैंने Parallel AI Agents से 4 दिनों में 39 लाख शब्दों का अनुवाद किया
17 सालों की 493 ब्लॉग पोस्ट्स, 10 भाषाओं में अनुवादित, ~4,900 फ़ाइलें, ~39 लाख शब्द। Claude Code के parallel agents ने इसे संभव बनाया — लेकिन Korean की तबाही, Cantonese की आवाज़ की समस्या, और 5 घंटे की usage cap ने सफलताओं से ज़्यादा सिखाया।
एक महीने पहले, मैंने DIALØGUE में 48 घंटों में 5 भाषाएँ जोड़ीं और लिखा कि कैसे planning documents तेज़ AI execution का रहस्य हैं।
वो 5 भाषाएँ थीं एक single ऐप के लिए जिसमें शायद 400 UI strings थीं।
इस हफ़्ते, मैंने कुछ बहुत बड़ा try किया: अपने पूरे ब्लॉग को localize करना — 17 सालों की 493 पोस्ट्स — 10 भाषाओं में। वियतनामी, इंडोनेशियाई, स्पेनिश, फ्रेंच, पुर्तगाली, जर्मन, जापानी, कोरियन, सिम्प्लिफ़ाइड चाइनीज़, और कैंटोनीज़।
~4,900 अनुवादित फ़ाइलें। ~39 लाख शब्द। 4 दिन।
यह AI के जादुई होने की कहानी नहीं है। यह उसकी कहानी है जो असल में होता है जब आप हज़ारों translation tasks parallel AI agents पर फेंकते हैं — कौन सा orchestration काम करता है, कौन सी failures output पढ़ने तक नहीं दिखतीं, और quality control के बारे में वो असहज सच्चाई जब machines बड़े पैमाने पर लिखती हैं।
पैमाने की समस्या
मेरा ब्लॉग 2007 से शुरू होता है। कुछ पोस्ट्स Singapore में search marketing पर 300 शब्दों के अपडेट हैं। दूसरी US-China संबंधों या expat relocation guides पर 5,000 शब्दों की गहरी पड़ताल। Archive में Yahoo SEM analytics से लेकर book reviews से लेकर AI product launches तक सब कुछ है।
493 पोस्ट्स को 9 भाषाओं में manually translate करने में professional translation team को हफ़्ते लगते। शायद महीने। और लागत "असहज" से "घर गिरवी रखो" के बीच कहीं होती।
लेकिन मैंने पहले ही i18n infrastructure बना लिया था — next-intl routing, locale-aware components, non-English pages के लिए ISR — एक बड़े internationalization push के हिस्से के रूप में। Technical stack तैयार था। बस content चाहिए था।
Day 1: वियतनामी और पहले सबक
मैंने वियतनामी से शुरू किया क्योंकि यह personal है — यह मेरी पहली भाषा है। मैं हर translated post पढ़ सकता था और तुरंत बता सकता था कि कुछ गलत लग रहा है या नहीं।
Claude Code ने एक session में सभी 493 पोस्ट्स translate कीं। प्रक्रिया साफ़ दिखी:
- English MDX file पढ़ो
- Content translate करो, सारा frontmatter structure preserve करो
- URLs, code blocks, और technical terms intact रखो
- Translated file
content/blog/vi/YYYY/MM/DD/slug.mdxमें लिखो - "Cheers, Chandler" के Vietnamese equivalent से sign off करो
पहली QA pass ने वो pattern पकड़ा जो हर भाषा में haunt करेगा: URLs और sign-offs। Agent internal blog URLs को "translate" कर देता (जैसे /blog/2024/... को Vietnamese slugs में बदलना जो exist नहीं करते), "Chandler" को Vietnamese name variant से replace कर देता, और कभी-कभी frontmatter slug field ही खो देता।
मैंने एक QA checklist बनाई:
- File count source से match करे (493)
- कोई empty या stub files नहीं
- सभी frontmatter में
slug,title,date,categoriesहो - कोई rewritten internal URLs नहीं
- Sign-off target locale के convention से match करे
- CJK भाषाओं के लिए: native characters actually present हों
वो checklist हर बाद के locale की रीढ़ बन गई।
Day 2: Parallel Agent Breakthrough
Vietnamese done होने और QA checklist proven होने के बाद, मुझे और तेज़ जाना था। इस तरह के काम के लिए Claude Code का killer feature है parallel subagent dispatch — आप कई independent agents spin up कर सकते हैं जो अलग-अलग files पर simultaneously काम करते हैं।
Spanish के लिए orchestration कुछ ऐसा दिखा:
30 translation agents dispatch कर रहे हैं...
├── Agent 1: 2007-2008 posts (42 posts)
├── Agent 2: 2009 posts (38 posts)
├── Agent 3: 2010-2011 posts (35 posts)
├── ...
├── Agent 28: 2025 Nov-Dec posts (12 posts)
├── Agent 29: 2026 Jan posts (8 posts)
└── Agent 30: 2026 Feb posts (9 posts)
हर agent को posts का batch, style guide, QA checklist, और sign-off convention मिला। वे parallel में चले, independently files लिखते हुए। Coordination की ज़रूरत नहीं क्योंकि हर agent अलग files touch करता है।
Spanish: एक session में 493 posts translate। फिर French। फिर Portuguese। फिर German। फिर Japanese।
लगभग 12 घंटों में पाँच भाषाएँ। यही वो हिस्सा है जो future जैसा लगता है — अपने terminal को 30 simultaneous progress indicators से भरते देखना, हर agent एक दशक की blog posts चबाता हुआ जबकि आप खाना बना रहे हैं।
यहाँ एक simulation है कि Cantonese (zh-HK) translation session असल में कैसा दिखा — planning से dispatch से QA तक:
Orchestration Pattern
जो pattern उभरा:
- सभी directories पहले से बनाओ — अगर target directory exist नहीं करती तो agents चुपचाप fail हो जाते हैं
- Year range से batch करो — normal posts के लिए 10-15 posts per agent, 3,000+ शब्दों की posts के लिए 2-3 per agent
- हर dispatch में style guide शामिल करो — agents की shared memory नहीं होती, इसलिए हर एक को full context चाहिए
- हर locale complete होने के बाद QA चलाओ — file count, empty files, broken frontmatter, URL rewrites, sign-off consistency
- Targeted cleanup agents से stragglers fix करो — हमेशा 5-15 posts होती हैं जो miss या malformed हो जाती हैं
Korean की तबाही
Korean routine होना चाहिए था। बाकी 7 भाषाओं जैसा ही pattern। Agents dispatch करो, इंतज़ार करो, QA करो, stragglers fix करो।
इसके बजाय, यह किसी भी locale की सबसे खराब translation quality थी।
72% Korean posts translations नहीं थीं — वे summaries थीं। Agents ने 350+ posts को 2-3 paragraph abstracts में truncate कर दिया था, सारी detail, सारी personality, सारी nuance खो दी। Ray Dalio की "Principles" पर 4,000 शब्दों का analysis 200 शब्दों का overview बन गया। एक detailed SEM tutorial "यह पोस्ट search engine marketing strategies पर चर्चा करती है" बन गया।
UI strings file (messages/ko.json) और भी बदतर थी। पूरे में mixed Korean और English, corrupted characters जैसे "Ch및ler" जो "Chandler" होना चाहिए था। 및 Korean में "and" है — model ने किसी तरह mid-word substitute कर दिया।
मुझे पूरा locale scratch से redo करना पड़ा। हर single post। दूसरी बार, full content preserve करने और source post की length match करने के stricter instructions के साथ, साफ़ आया।
सबक: parallel execution गलतियों को amplify करता है। अगर आपके prompt में subtle flaw है, 30 agents 30 गुना तेज़ी से वही गलती करेंगे। QA optional नहीं है — यही एकमात्र चीज़ है "done" और "तबाही" के बीच।
Chinese की समस्या: सही करने में 43 Commits
Simplified Chinese (zh) सबसे labor-intensive locale रहा। Quality issues की वजह से नहीं — translations अच्छी थीं — बल्कि 43 अलग commits में 493 posts बताती हैं कि session बार-बार limits hit कर रहा था।
Claude Code Anthropic के API पर चलता है, और usage cap है। Max tier पर Sonnet 4.6 के साथ भी, extended sessions जो dozens of parallel agents dispatch करती हैं, eventually 5-घंटे की cooling period hit करेंगी। Chinese के लिए, इसका मतलब waves में translate करना था: ~50 posts, cap hit, wait, continue, फिर cap hit।
Chinese translations को सबसे ज़्यादा QA भी चाहिए क्योंकि CJK content के unique failure modes हैं:
- गलत script के characters (Japanese kanji Simplified Chinese में mixed)
- ज़रूरत से ज़्यादा formal register जो blog की जगह government document जैसा लगे
- Chinese punctuation की जगह Western punctuation (，बनाम , और 。बनाम .)
- ऐसे translated names जिन्हें translate नहीं होना चाहिए ("Claude" Chinese में "Claude" है, 克劳德 नहीं)
Cantonese आवाज़ की समस्या
जब मैंने Cantonese voice के साथ Traditional Chinese (zh-HK) जोड़ा, तो बिल्कुल अलग challenge सामने आया। Translations में Cantonese-specific particles चाहिए थे — 嘅 (possessive), 咗 (past tense), 喺 (at/in), 啲 (some), 冇 (don't have) — और वो casual, conversational tone maintain करना था जो Cantonese writing को define करता है।
Standard Mandarin translations Hong Kong में bureaucratic लगती हैं। "本网站提供中文版本" correct Mandarin है, लेकिन Cantonese reader expect करता है "呢個網站有中文版本।" Same meaning, बिल्कुल अलग voice।
Challenge translation accuracy नहीं है — voice authenticity है। Model grammatically correct Cantonese produce कर सकता है, लेकिन जब तक explicitly instruct न करो colloquial particles और code-mixing patterns use करने के लिए, यह Mandarin register पर default करता है।
Cantonese के लिए मेरी QA check में हर file में Cantonese-specific particles की presence grep करना शामिल था। 493 में से 493 pass हुईं। लेकिन मुझे फिर भी पूरी messages/zh-HK.json UI strings file manually rewrite करनी पड़ी क्योंकि पहला version ~70% English था — agent ने ज़्यादातर translations skip कर दिए थे।
OpenAI Codex के साथ क्या try किया
German translations के आसपास कहीं, मैंने Claude Code की usage cap hit की और wait करते हुए OpenAI का Codex try करने का फ़ैसला किया। मेरे पास ChatGPT Plus का free month था, जिसमें Codex access शामिल है।
अच्छा: Codex solid planning documents produce करता है। Codebase का initial analysis और proposed translation approach well-structured और reasonable था। Response times तेज़ थे। और यह instructions closely follow करता है — लगभग ज़्यादा ही closely, जो एक feature हो सकता है।
बुरा: जो version मैंने use किया (gpt-5.2-codex) parallel subagents नहीं चला सकता था। यह posts sequentially process करता था — एक-एक करके। 493 posts के लिए, यह viable नहीं है। यह short bursts में भी काम करता था, 5-10 posts complete करके feedback माँगने रुक जाता। हर बार, मुझे "continue" कहना पड़ता अगला batch पाने के लिए।
जब mid-session gpt-5.3-codex available हुआ, मैंने switch किया। बेहतर, लेकिन फिर भी no parallel execution। Fundamental architectural difference — Claude Code 30+ independent agents dispatch कर सकता है जो simultaneously चलते हैं, जबकि Codex single sequential process के रूप में operate करता है — bulk content tasks के लिए Claude Code को dramatically faster बनाता है।
ईमानदार comparison: Codex focused, single-file work के लिए अच्छा है। यह responsive है और directions अच्छी तरह follow करता है। लेकिन जिस तरह का mass parallel execution मुझे चाहिए था — 9 locales में 4,437 files — उसके लिए Claude Code का agent architecture बिल्कुल अलग category में है।
वो Checklist जिसने सब कुछ बचाया
हर locale ने same QA pipeline follow किया:
✓ File count: 493/493
✓ Empty files: 0
✓ Small files (<100 bytes): 0
✓ Missing slugs: 0
✓ Rewritten URLs: 0
✓ Broken frontmatter: 0
✓ Wrong sign-off: 0
✓ Native characters present: 493/493
CJK भाषाओं के लिए, मैंने जोड़ा:
✓ Cantonese particles (嘅/咗/喺/啲/冇): 493/493
✓ No mixed-script contamination: PASS
✓ Chinese punctuation: PASS
इस checklist के बिना, मैंने Korean summaries production में ship कर दिए होते। मैंने 70% English Cantonese UI ship कर दिया होता। मैंने broken internal links वाले blog posts ship कर दिए होते जो translated slugs पर point करते हैं जो exist नहीं करते।
Checklist bureaucracy नहीं है। यह एकमात्र reliable QA है जब आपकी production pipeline हज़ारों files generate करती है जो आप personally नहीं पढ़ सकते।
Final Numbers
| भाषाएँ | 11 (English + 10 translations) |
| Translated posts | 493 per language × 10 = ~4,900 files |
| शब्द | ~39 लाख |
| Calendar days | 4 (24-27 फरवरी) |
| UI string files | 10 locale JSON files (~475 keys each) |
| Email templates | 10 locales |
| Journey data | Milestones + learning paths JSONB से translated |
| Usage cap hit | गिनती खो दी |
| Complete locale redos | 1 (Korean) |
मैंने असल में क्या सीखा
1. Style guides ही सब कुछ हैं। Cantonese voice, Korean formality level, Portuguese "Abraço" sign-off — ये decoration नहीं हैं। ये "translated" और "localized" के बीच का फ़र्क हैं। Style guide के बिना, आपको grammatically correct content मिलता है जो government form जैसा पढ़ता है।
2. Parallel agents force multiplier हैं — और risk multiplier भी। जब 30 agents correctly execute करते हैं, एक भाषा एक घंटे में हो जाती है। जब 30 agents वही गलती execute करते हैं, आपको 350 truncated posts और full redo मिलता है।
3. Scale पर QA optional नहीं है। आप 4,437 translated posts manually review नहीं कर सकते। लेकिन आप structural checks automate कर सकते हैं जो सबसे common failures पकड़ें: missing files, broken frontmatter, rewritten URLs, wrong sign-offs, truncated content।
4. सबसे मुश्किल हिस्सा translation नहीं है — voice है। कोई भी LLM text translate कर सकता है। इसे ऐसा sound कराना जैसे वही इंसान बोल रहा है जिसने original लिखा — वो warmth, वो casualness, वो intellectual curiosity — 9 भाषाओं और 17 सालों की evolving writing style में बनाए रखना, इसके लिए explicit instruction और iterative refinement चाहिए।
5. Usage caps एक real constraint हैं। सबसे ऊँचे tier पर भी, extended parallel agent sessions limits hit करेंगी। Interruptions के लिए plan करो। अपना काम ऐसे structure करो कि जहाँ छोड़ा वहाँ से pick up कर सको।
6. Real readers से test करो। मैं Vietnamese translations खुद QA कर सकता था। Korean या Japanese के लिए, मैंने structural checks पर rely किया और model पर trust किया। यह एक known gap है। अगर आप ऐसी भाषाओं में quality को लेकर serious हैं जो आप नहीं बोलते, तो native readers से sample spot-check कराओ।
क्या यह worth था?
मेरा ब्लॉग अब 11 locales में readers तक उनकी native language में पहुँचता है। Ho Chi Minh City में एक Vietnamese marketing professional मेरा 2011 का Singapore search market analysis Vietnamese में पढ़ सकता है। एक Japanese AI researcher मेरे 2024 के Sydney बनाने के बारे में posts Japanese में पढ़ सकता है। Hong Kong में एक Cantonese speaker को ऐसा content मिलता है जो लगता है कि उनके लिए लिखा गया, उन पर translated नहीं किया गया।
क्या हर translation perfect है? नहीं। इस scale पर machine translation में rough edges हैं। कुछ metaphors land नहीं करते। कुछ cultural references को word-for-word substitution से आगे जाकर localization चाहिए।
लेकिन alternative था सिर्फ English में 493 posts, जो शायद दुनिया के 20% internet users तक accessible। अब 60% से ज़्यादा तक accessible है।
चार दिन। 39 लाख शब्द। Infrastructure ready है। मैं English में जो भी नई post लिखता हूँ वो deployment process के हिस्से के रूप में 10 भाषाओं में translate हो जाती है।
असली सवाल यह नहीं है कि AI translation perfect है या नहीं। सवाल यह है कि perfect, accessible का दुश्मन तो नहीं।
शुभकामनाओं सहित, Chandler
