Crowdin ने अभी एक i18n एजेंट स्किल लॉन्च की है। हमारे पास मार्च से एक मौजूद है।

Crowdin ने अगस्त में एक एजेंट स्किल जारी की जो किसी JavaScript ऐप को हार्डकोडेड स्ट्रिंग्स से एक कनेक्टेड Crowdin प्रोजेक्ट तक ले जाती है, और पिछले हफ्ते उन्होंने इसका एक वॉकथ्रू भी प्रकाशित किया। हमें खुशी है कि उन्होंने ऐसा किया। globalize.now एक AI-पावर्ड स्थानीयकरण इंफ्रास्ट्रक्चर है, हमारे पास मार्च से ही यह काम करने वाली एजेंट स्किल्स हैं, और 2008 में स्थापित एक कंपनी का भी इसी डिज़ाइन पर पहुंचना अब तक का सबसे साफ संकेत है कि यह समस्या वास्तविक है।

यह दोनों तरीकों की ईमानदारी से तुलना करने का भी सही मौका है, क्योंकि दोनों बहुत अलग जगहों पर खत्म होते हैं। उनका तरीका आपकी फ़ाइलों को एक ट्रांसलेशन मैनेजमेंट सिस्टम के भीतर पहुंचाकर खत्म होता है, जिसे फिर आपको खुद चलाना पड़ता है। हमारा तरीका एक पुल रिक्वेस्ट पर खत्म होता है जिसमें ट्रांसलेशन पहले से ही मौजूद होते हैं।

Crowdin ने वास्तव में क्या लॉन्च किया?

चार नई एजेंट स्किल्स, एक दोबारा लिखा गया CLI, और एक प्लगइन जो इन्हें उनके MCP सर्वर के साथ बंडल करता है। 4 सितंबर को प्रकाशित अगस्त चेंजलॉग में i18n-setup, glossary-generation, crowdin-cli और github-action सूचीबद्ध हैं। ये उन कॉन्टेक्स्ट और API-क्वेरी स्किल्स के साथ जुड़ती हैं जो Crowdin फरवरी से crowdin/skills में जोड़ रहा था।

CLI 5.0 इस रिलीज़ की सबसे बेहतरीन इंजीनियरिंग है। यह Java से TypeScript में शिफ्ट हुआ, अब एक सिंगल बाइनरी के रूप में शिप होता है, और एजेंट के पढ़ने के लिए JSON प्रिंट करता है। Crowdin इसे "AI एजेंट्स के लिए बनाया गया" कहता है, और यह सही भी है।

मुख्य आकर्षण i18n-setup है। 16 सितंबर को Crowdin ने इसका सात मिनट का वीडियो पोस्ट किया, जिसमें इसे Claude Code में एक छोटी सैंपल साइट पर चलाकर दिखाया गया।

पहले किसने क्या लॉन्च किया?

यह इस पर निर्भर करता है कि आप किसे गिनते हैं, इसलिए हमने तीनों रिपॉजिटरी की कमिट हिस्ट्री पढ़ी। Lingui ने जनवरी में सबसे पहले एजेंट स्किल्स प्रकाशित की थीं। किसी रिपो में i18n सेटअप करने वाली और हार्डकोडेड स्ट्रिंग्स को रैप करने वाली पहली स्किल हमारी थी, 29 मार्च को।

जो श्रेय बनता है, वह दें: Crowdin का MCP सर्वर हमारी कंपनी से भी पुराना है, और उनकी स्किल्स रिपॉजिटरी हमारी रिपॉजिटरी से पांच हफ्ते पुरानी है। शुरुआती Crowdin स्किल्स ने एजेंट को ट्रांसलेटर कॉन्टेक्स्ट लिखना सिखाया था। एप्लिकेशन कोड को छूना बाद में आया। हमारी सेटअप और स्ट्रिंग-रैपिंग स्किल्स 29 मार्च से हैं, और पूरी यात्रा चलाने वाला ऑर्केस्ट्रेटर 5 अप्रैल से। Crowdin का समकक्ष 28 अगस्त को आया, यानी Lingui द्वारा वह सेटअप स्किल जोड़े जाने के दो हफ्ते बाद जिस पर यह निर्भर करता है, और उसी ढांचे के साथ: पता लगाना, फ़ैसला करना, सेटअप करना और रैप करना।

हम इसे कॉपी करने का सबूत नहीं, बल्कि डिज़ाइन के लिए एक तारीफ़ मानते हैं। एक बार जब आप इस आधार को स्वीकार कर लेते हैं, तो यह सबसे स्पष्ट आकार बन जाता है, और वीडियो इसी आधार से शुरू होता है: "प्रोडक्ट प्रोडक्शन के लिए तैयार हो सकता है, लेकिन इसका मतलब यह नहीं कि वह ट्रांसलेशन के लिए तैयार है।" हमने भी मार्च में अपनी पहली पोस्ट में यही बात कही थी।

इन तीनों के अलावा भी कुछ अन्य वेंडर्स ने i18n को एक एजेंट के पीछे रखा है, इसलिए हम यह दावा नहीं कर रहे कि यह दुनिया में पहली बार हुआ है।

Crowdin की i18n-setup स्किल क्या करती है?

यह आपके ही कोडिंग एजेंट के भीतर सात चरणों में चलती है और आपके रिपो में एक रीज़्यूमेबल चेकलिस्ट रखती है। स्किल फ़ाइल अच्छी तरह व्यवस्थित है, और वॉकथ्रू उससे मेल खाता है।

1. पता लगाना। फ्रेमवर्क और किसी मौजूदा i18n लाइब्रेरी के लिए रिपो को स्कैन करना।
2. फ़ैसला करना। पूछना कि आपको कौन-सी भाषाएं चाहिए और क्या गाइडेड या अनगाइडेड तरीके से आगे बढ़ना है, फिर एक plan.md लिखना।
3. सेटअप करना। Lingui इंस्टॉल और कॉन्फ़िगर करना। यदि आपके पास पहले से कोई लाइब्रेरी है, तो यह आपकी लाइब्रेरी को बनाए रखता है।
4. रैप करना। यूज़र-फेसिंग स्ट्रिंग्स को मार्क करना और PO फ़ाइलें निकालना।
5. कनेक्ट करना। CLI से एक Crowdin प्रोजेक्ट बनाना और फ़ाइलें अपलोड करना। इसके लिए आपके Crowdin टोकन की जरूरत होती है।
6. कॉन्टेक्स्ट। हर स्ट्रिंग के आसपास के कोड को पढ़ना और ट्रांसलेटर्स के लिए एक नोट लिखना। एक स्टार्टर ग्लॉसरी सुझाना।
7. CI। एक GitHub वर्कफ़्लो इंस्टॉल करना ताकि नई स्ट्रिंग्स Crowdin तक पहुंचें और ट्रांसलेशन वापस आएं।

एक बात जिसे वीडियो में नहीं दिखाया गया: Crowdin की स्किल खुद चरण 3 और 4 नहीं करती। इसका मैनिफेस्ट इन्हें Lingui की अपनी स्किल्स को सौंप देता है, जिन्हें आपको एक दूसरे प्लगइन के रूप में इंस्टॉल करना पड़ता है। Crowdin का अपना काम चरण 5 से शुरू होता है।

इसमें से कुछ हिस्सा अच्छी तरह सोचा गया है। एजेंट कभी आपके टोकन की वैल्यू नहीं देखता, और जब कुछ अस्पष्ट होता है तो स्किल पूछने के लिए रुक जाती है। सीमाएं भी फ़ाइल में साफ लिखी हैं। नए इंस्टॉल केवल Lingui के लिए हैं और दायरा JavaScript और TypeScript तक सीमित है। जो प्रोजेक्ट्स पहले से i18next, next-intl या vue-i18n पर हैं, उन्हें सिर्फ़ कनेक्ट करने का रास्ता मिलता है। यह Create React App को मान्य नहीं करता, और यह आपको लाइब्रेरीज़ के बीच माइग्रेट नहीं करेगा।

यह आपके लिए क्या छोड़ता है?

ट्रांसलेशन, और वह सब कुछ जो ट्रांसलेशन होने के लिए ज़रूरी है। सातों चरणों को फिर से पढ़ें: इनमें से कोई भी एक ट्रांसलेट की गई स्ट्रिंग नहीं देता।

यह जानबूझकर किया गया है। स्किल फ़ाइल में ऑटो-ट्रांसलेट को एक ऐड-ऑन के रूप में सूचीबद्ध किया गया है जो डिफ़ॉल्ट रूप से बंद रहता है, साथ ही यह निर्देश है कि "बिना पूछे किसी नए प्रोजेक्ट को कभी मशीन-ट्रांसलेट न करें"। यदि आप इसे चालू करते हैं, तो एजेंट केवल ट्रांसलेशन मेमोरी लागू कर सकता है, और एक नए प्रोजेक्ट में यह मेमोरी होती ही नहीं। मशीन या AI ट्रांसलेशन तभी की अनुमति है जब आपके Crowdin अकाउंट में पहले से कोई इंजन या प्रॉम्प्ट मौजूद हो।

स्किल पूरी होने के बाद आपके पास एक Crowdin प्रोजेक्ट होता है, और आपको Crowdin आना जानना पड़ता है। AI ट्रांसलेशन पाने के लिए आप अपनी प्रोफ़ाइल खोलते हैं, अपने API key से या Crowdin बैलेंस में पैसे जोड़कर एक प्रोवाइडर सक्षम करते हैं, और एक प्रॉम्प्ट बनाते हैं। फिर आप एडिटर से प्री-ट्रांसलेशन चलाते हैं, या CLI से उस प्रॉम्प्ट ID के साथ जो आपने अभी बनाया है, या फिर प्रोजेक्ट-लेवल का ऑटो-ट्रांसलेट सेटिंग चालू करते हैं। इसके बाद अप्रूवल्स के बारे में सोचना पड़ता है, फिर एक बिल्ड, फिर एक डाउनलोड।

यह सब कोई ऐसा व्यक्ति ऑटोमेट कर सकता है जो पहले से जानता हो कि वे सेटिंग्स कहां हैं। यही मुश्किल है। एजेंट ने वह हिस्सा किया जो एक डेवलपर समझता है, फिर एक ऐसा प्रोडक्ट सौंप दिया जो स्थानीयकरण मैनेजर्स के लिए बनाया गया है। Crowdin के अपने वॉकथ्रू में भी, प्रेजेंटर अपनी चीनी स्ट्रिंग्स पाने के लिए एडिटर खोलता है, मशीन ट्रांसलेशन पर क्लिक करता है, और CLI से नतीजा वापस खींचता है।

Crowdin का MCP सर्वर इस कमी को नहीं भरता। इसके दर्ज टूल सेट किसी मौजूदा प्रोजेक्ट के भीतर काम करते हैं, और हमें डॉक्स में कोई प्री-ट्रांसलेशन या प्रोजेक्ट-निर्माण टूल नहीं मिला। यह एक डॉक्यूमेंटेशन रीडिंग है, हर टूल की टेस्टिंग नहीं।

globalize.now कैसे अलग है?

i18n कन्वर्शन और ट्रांसलेशन एक ही काम है, और नतीजा एक पुल रिक्वेस्ट होता है। कहीं और कोई प्रोजेक्ट कॉन्फ़िगर करने की ज़रूरत नहीं, क्योंकि कोई 'कहीं और' है ही नहीं।

डिफ़ॉल्ट रास्ता ऐप के भीतर है। आप साइन अप करते हैं, GitHub या GitLab कनेक्ट करते हैं, और एक रिपो चुनते हैं। एक स्कैन तय करता है कि आगे क्या होगा। यदि अभी तक कोई i18n नहीं है, तो हम आधारभूत काम जोड़ देते हैं। यदि आप पहले से next-intl, react-i18next, i18next या Lingui का उपयोग करते हैं, तो हम आपके मौजूदा सेटअप से कनेक्ट करते हैं और आपकी फ़ाइल संरचना को नहीं छूते। आप योजना को मंज़ूरी देते हैं। इसके बाद कन्वर्शन और ट्रांसलेशन आपके रिपो की एक क्लोन पर, हमारे क्लाउड में, समांतर रूप से चलते हैं, और अपनी ही ब्रांच में जाकर पहुंचते हैं। जब तक आप मर्ज नहीं करते, आपकी डिफ़ॉल्ट ब्रांच को कुछ नहीं छूता।

वह पहला कन्वर्शन एक बार होता है। इसके बाद, जब भी आप नई सोर्स स्ट्रिंग्स पुश करते हैं, एक पुश जॉब उन्हें ट्रांसलेट करके एक पुल रिक्वेस्ट खोल देती है।

यदि आप अपने एडिटर में ही रहना पसंद करते हैं, तो यही काम एक प्रॉम्प्ट से शुरू होता है। हमारा Claude Code इंटीग्रेशन और इसके पीछे की स्किल्स आपके लिए रिपो को कनेक्ट कर देती हैं। हमने पहले भी लिखा है कि हम SDK के बजाय एक स्किल क्यों शिप करते हैं।

Crowdin के सात चरण आपके एजेंट पर चलते हैं, इसलिए वे आपके टोकन खर्च करते हैं। हमारा कन्वर्शन हमारी तरफ़ चलता है। और जिसने अपना ऐप Lovable में बनाया है और कभी टर्मिनल नहीं खोला, वह भी हमारा फ़्लो पूरा कर सकता है, जो किसी भी उस प्रक्रिया के साथ सच नहीं है जो एनवायरनमेंट वेरिएबल एक्सपोर्ट करने से शुरू होती है।

यह तुरंत नहीं होता। छोटे रिपो मिनटों में हो जाते हैं और एक बड़ा कोडबेस एक घंटे या उससे ज़्यादा भी ले सकता है। फिर भी आप एक योजना पढ़ते हैं और एक PR रिव्यू करते हैं, जैसा कि होना भी चाहिए।

Crowdin i18n-setup बनाम globalize.now, चरण-दर-चरण

आपको Crowdin कब चुनना चाहिए?

जब आपके प्रोडक्ट को लोग ट्रांसलेट करते हैं। यदि आपके पास इन-हाउस भाषाविद हैं, कोई एजेंसी है, या वॉलंटियर्स का समुदाय है, तो आपको ट्रांसलेशन मेमोरी, ग्लॉसरी, इन-कॉन्टेक्स्ट एडिटर, रिव्यू स्टेप्स और वेंडर हैंडलिंग की ज़रूरत होती है। यह एक ट्रांसलेशन मैनेजमेंट सिस्टम है, Crowdin 2008 से यही बना रहा है, और हम वैसा बनने की कोशिश नहीं कर रहे।

Crowdin ऐसे फ़ॉर्मेट भी हैंडल करता है जिन्हें हम आज सपोर्ट नहीं करते, जिनमें XLIFF, ARB, .xcstrings और Android XML शामिल हैं, और इसकी स्किल एक vue-i18n प्रोजेक्ट को कनेक्ट कर सकती है। यदि आपका मुख्य प्रोडक्ट एक नेटिव मोबाइल ऐप है, तो सबसे पहले यही जांच लें।

पूरा तुलना पेज प्राइसिंग मॉडल और टीम फ़िट के बारे में और गहराई से बताता है।

एक स्थापित कंपनी का यह शिप करना क्यों मायने रखता है?

क्योंकि यह एक बहस को सुलझा देता है। अब Lingui, Crowdin और हम, तीनों इस बात पर सहमत हैं कि कोड तैयार करने का काम एजेंट को करना चाहिए, डेवलपर को खुद काम करने के बजाय एक योजना मंज़ूर करनी चाहिए, और यह सब उसी एडिटर में होना चाहिए जहां ऐप लिखा जा रहा है।

जहां हमारी असहमति अब भी बनी है, वह यह है कि इसके बाद क्या होता है। Crowdin का जवाब है डैशबोर्ड तक एक बेहतर रास्ता। हमारा मानना है कि Cursor, Claude Code या Lovable के साथ शिप करने वाली ज़्यादातर टीमों को कोई डैशबोर्ड नहीं चाहिए। उन्हें दिन खत्म होने से पहले अपना ऐप जर्मन में चाहिए, और हर बार जब वे एक बटन जोड़ें, एक PR चाहिए।

किसी भी वेंडर से, जो एजेंट की कहानी सुनाता है, पूछने लायक सवाल सीधा है: एजेंट का काम पूरा होने के बाद, मुझे आगे कहां जाना पड़ता है? यदि जवाब है किसी नए प्रोडक्ट को सीखना, तो एजेंट सिर्फ़ एक दरवाज़ा था। यदि जवाब है आपका पुल रिक्वेस्ट टैब, तो वह पूरा घर था।

अपने ही रिपो पर इसे आज़माएं

वही टेस्ट करें जो Crowdin ने किया: हार्डकोडेड स्ट्रिंग्स वाला एक छोटा ऐप लें और एक घंटे बाद देखें कि आप कहां पहुंचे हैं। एक रिपॉजिटरी कनेक्ट करें, योजना मंज़ूर करें, पुल रिक्वेस्ट पढ़ें। ट्रायल के लिए किसी कार्ड की ज़रूरत नहीं। यदि पहले जानना चाहते हैं तो प्राइसिंग यहां है।