जब कोई AI agent वास्तविक monorepo को internationalize करता है, तो क्या होता है?

इसने UI strings के 28 candidates निकाले, कई files में translation की 41 entries rewrite कीं, middleware और routing configure की और 5 target languages के लिए locale files generate कीं। Setup, conversion और translation में end-to-end लगभग 90 मिनट लगे। globalize.now AI-powered localization infrastructure है, और हमने इसे production monorepo पर चलाकर देखा कि वास्तव में क्या होता है। कोई curated demo नहीं। कोई safety net नहीं। बस वास्तविक complexity वाला वास्तविक codebase।

यह codebase localization industry के एक अनुभवी व्यक्ति का था, जिन्होंने leading translation management platforms में से एक में एक दशक से अधिक समय तक architect के रूप में काम किया था।

Monorepo में क्या था?

यह कोई tutorial project नहीं था। Monorepo में Next.js web application, Android app, MCP servers और third-party service से render होने वाला documentation शामिल था। Developer रोज़ Claude Code इस्तेमाल करते हैं, end-to-end AI tooling के साथ build करते हैं और उन्होंने पूरा stack तीन महीनों में तैयार किया था।

Target Next.js frontend था। Android app, MCP servers और Mintlify पर बना docs site—इनमें से किसी को छूना नहीं था। सवाल यह था कि क्या AI agent को बिना स्पष्ट रूप से बताए यह समझ आएगा।

समझ आया। Agent ने पूरा repo scan किया और Next.js application पर focus किया। व्यवहार में manual scoping की ज़रूरत नहीं पड़ी, हालांकि developer ने कहा कि मन की शांति के लिए “केवल /apps/web convert करें” कह पाने का विकल्प उपयोगी होता। यह उचित सुझाव है और इसे जोड़ना अच्छा रहेगा। लेकिन इससे conversion रुका नहीं।

Configuration कैसे काम करती थी?

Process समझने के लिए developer ने guided mode चुना। Configuration में पाँच फ़ैसले शामिल थे: package manager (NPM, हालांकि legacy PNPM lockfile भी मौजूद था), catalog format (PO/GetText, comment support के लिए recommended), setup mode (guided), source language (English) और target languages (Spanish, Italian, Hungarian, Czech, Slovak)।

एक बात ध्यान देने योग्य है: catalog format वाला सवाल गहरी localization expertise रखने वाले व्यक्ति के लिए भी झिझक का कारण बना। उनकी प्रतिक्रिया सीधी थी। उन्हें नहीं लगा कि यह चुनाव इतना महत्वपूर्ण है कि user से पूछा जाए। इसे automate करें।

Routing strategy path-based थी। Domain-based routing नहीं अपनाई गई, क्योंकि developer के पास अतिरिक्त domains नहीं थे। App OAuth-based authentication इस्तेमाल करती है, इसलिए login flows को जानबूझकर English में रखा गया। Agent ने इसे सही ढंग से संभाला।

Conversion step वास्तव में क्या करता है?

यही वह हिस्सा है जो मायने रखता है। एजेंट ने Next.js ऐप में UI स्ट्रिंग के 28 संभावित स्थान पहचाने और 41 अनुवाद प्रविष्टियों को प्रोसेस किया। उसने फ़ाइलों को पुनर्गठित किया, middleware अपडेट किया, component imports बदले और सभी 5 लक्षित भाषाओं के लिए PO locale files जनरेट कीं।

सिर्फ़ conversion step में लगभग 30 मिनट लगे। उससे पहले का setup और configuration, और उसके बाद developer द्वारा translation connection को स्वतंत्र रूप से पूरा करने का समय जोड़ें, तो पूरा end-to-end flow लगभग 90 मिनट का रहा। यह तुरंत होने वाली प्रक्रिया नहीं है। संदर्भ के लिए, कुछ ही पेज वाले सरल ऐप में पूरा flow 15 मिनट से कम समय में पूरा हो जाता है। दर्जनों अनुवाद योग्य surfaces वाले जटिल ऐप में अधिक समय लगता है। समय repo के आकार से नहीं, strings की संख्या के साथ बढ़ता है।

Developer ने conversion step को चलते हुए देखा और कहा: string extraction और code rewriting ही असली मेहनत है। यही वह काम है जिससे developers सबसे ज़्यादा बचना चाहते हैं। उनकी पिछली कंपनी में, जो एक प्रमुख TMS थी, repo में मौजूद translation files तो केवल iceberg का ऊपरी सिरा थीं। असली परेशानी preparation और internationalization work में थी। AI agent ने ठीक इसी हिस्से को संभाला।

यह उस बात से मेल खाता है जो हम हर उस developer से सुनते हैं जिसने i18n manually किया है। शिकायत translations को लेकर नहीं होती। शिकायत होती है 40 files को छूकर strings को t() calls में wrap करने, समझदारी भरी keys बनाने, imports को पुनर्गठित करने और middleware configure करने को लेकर। यही वह काम है जिसे globalize.now automate करता है।

क्या यह सचमुच end-to-end काम किया?

हाँ। Live session समाप्त होने के बाद developer ने बाकी steps स्वतंत्र रूप से पूरे किए। उन्होंने globalize.now Git branch publish की, ऐप को web platform से जोड़ा, monitoring को globalize.now branch पर सेट किया और पुष्टि की कि files सही ढंग से upload और translate हुईं।

Czech translation quality पर उनका आकलन था: लगभग पूर्ण। यह ऐसे व्यक्ति का आकलन है जिसने अपना करियर localization output का पेशेवर मूल्यांकन करने में बिताया है। यह कोई सामान्य thumbs-up नहीं है। यह domain expert की पुष्टि है कि एक जटिल language pair के लिए quality production में इस्तेमाल करने योग्य है।

Flow को स्वतंत्र रूप से पूरा करने के बाद उन्होंने web app में दो समस्याएँ बताईं। पहली, repo को दोबारा scan करने पर “no i18n files detected” दिखा, जबकि translation job वास्तव में background में चल रही थी। यह भ्रामक UI state थी, वास्तविक failure नहीं। दूसरी, translation job बिना स्पष्ट consent के शुरू हो गई। Credits खर्च करने वाली किसी भी action के लिए confirmation आवश्यक होना चाहिए। दोनों मान्य UX issues हैं और इन पर काम चल रहा है।

क्या गड़बड़ हुई?

कुछ चीज़ें टूट गईं। यह एक वास्तविक test था, इसलिए हम इसके बारे में ईमानदार रहेंगे।

Installation command (npx skills add globalize-now/globalize-skills) Windows PowerShell पर विफल हो गई। Windows पर tool का यह पहला test था। Google द्वारा email attachment block किए जाने के बाद skills को Swiss Transfer के ज़रिए zip file के रूप में भेजना पड़ा। Actual flow शुरू होने से पहले setup friction कुल मिलाकर लगभग 15 मिनट रहा।

Conversion के बीच में ES modules और CommonJS के बीच conflict सामने आया। Project CommonJS का उपयोग करता है, लेकिन एक जगह agent के output ने ES modules मान लिए। यह blocker नहीं था, लेकिन setup के दौरान इसका पता लगना और इसे proactively संभाला जाना चाहिए।

Session के अंत में globalize.now web app में GitHub repository connect करने पर blank page दिखा। Developer Opera का उपयोग कर रहे थे। न login screen, न error, न content। समस्या हल होने से पहले session समाप्त हो गया।

तीन bugs। सभी वास्तविक। सभी ठीक किए जा चुके हैं या उन पर काम चल रहा है।

String extraction असली bottleneck क्यों है?

अधिकांश i18n content translation quality, framework configuration या TMS feature comparisons पर केंद्रित रहता है। इससे वह जगह छूट जाती है जहाँ developers वास्तव में समय गंवाते हैं।

मौजूदा codebase में internationalization जोड़ने का मतलब है हर component को scan करके hardcoded strings ढूँढना, तय करना कि कौन-सी strings translatable हैं, meaningful translation keys बनाना, हर string को उपयुक्त t() या <Trans> call में wrap करना, पूरे file tree में imports अपडेट करना, शुरुआती locale files बनाना और routing middleware configure करना। Monorepo में यह भी पता लगाना पड़ता है कि codebase के किन हिस्सों को i18n की ज़रूरत है।

यह tedious और error-prone काम है—और ठीक उसी तरह का काम है जिसमें AI agents अच्छे होते हैं। इसे होते हुए देखने वाले developer ने बात बिल्कुल स्पष्ट कही: developer के नज़रिए से यही असली मेहनत है। इससे बहुत राहत मिलती है। AI tools के साथ काम करने वाले Vibe coders अब global market में जाने की सबसे कठिन प्रक्रिया को पूरी तरह छोड़ सकते हैं।

Monorepo scoping के बारे में हमने क्या सीखा?

Agent ने monorepo scoping को implicitly संभाला। बिना बताए उसने Next.js web app पर ध्यान दिया और Android code, MCP servers तथा Mintlify docs को नज़रअंदाज़ किया। अधिकांश मामलों में यही सही व्यवहार है।

लेकिन implicit scoping और explicit scoping एक ही बात नहीं हैं। Developer चाहते थे कि configuration step के रूप में वे कह सकें, “सिर्फ़ मेरा Next.js app convert करें।” कई web frontends वाले monorepo में—मान लीजिए customer-facing app और admin dashboard—आप यह सटीक रूप से नियंत्रित करना चाहेंगे कि पहले किस frontend को internationalize किया जाए।

यह product gap है जिसे हम दूर कर रहे हैं। फिलहाल agent व्यवहार में सही परिणाम देता है। Explicit scoping को configuration step होना चाहिए, खासकर तब जब conversion दर्जनों files को प्रभावित करता हो।

यह manual i18n setup की तुलना में कैसा है?

इस जटिलता वाले codebase पर manual i18n setup में कई दिन लगते हैं। इसलिए नहीं कि कोई एक step कठिन है, बल्कि इसलिए कि steps दर्जनों हैं और हर एक पर ध्यान देना पड़ता है। एक string छूट जाए तो आधा-अधूरा translated page ship हो जाता है। Key name गलत हो जाए तो duplicate entries बनती हैं, जो महीनों तक परेशानी देती हैं। Middleware अपडेट करना भूल जाएँ तो locale routing चुपचाप टूट जाती है।

AI agent ने यही काम end-to-end लगभग 90 मिनट में पूरा कर दिया। Developer—जिन्होंने पेशेवर रूप से हजारों i18n implementations देखी हैं—ने इसे elegant कहा।

AI tools के साथ ऐप बनाने वाले developers के लिए इससे languages जोड़ने का सही समय बदल जाता है। अगर i18n setup में एक सप्ताह लगता है, तो product-market fit साबित होने तक आप इसे टालते हैं। अगर इसमें 90 मिनट लगते हैं, तो आप पहले दिन से multilingual product ship कर सकते हैं।

globalize.now यही काम संभालता है। अपना repository connect करें और conversion ऐप में एक बार चलता है; उसके बाद का काम आपके editor में npx skills add globalize-now/globalize-skills skills संभालती हैं। यह globalize.now पर देखें।