डैशबोर्ड के बिना Bolt.new ऐप को स्थानीयकृत कैसे करें?

आप Bolt.new ऐप को स्थानीयकृत करने के लिए प्रोजेक्ट को Git repository में ले जाते हैं और ट्रांसलेशन कैटलॉग को वहाँ कमिट की गई फ़ाइलों के रूप में रखते हैं। यही एक फ़ैसला है जो डैशबोर्ड को केवल वैकल्पिक नहीं बल्कि पूरी तरह अनावश्यक बना देता है। globalize.now AI-पावर्ड स्थानीयकरण इंफ्रास्ट्रक्चर है: यह keys और locale files तैयार करता है, और आप जो भी runtime library पहले से इस्तेमाल कर रहे हैं वही उन्हें सर्व करती है। Bolt आपको एक होस्टेड पेज नहीं, बल्कि एक असली कोडबेस देता है, इसलिए repo-native रास्ता पहले प्रॉम्प्ट से ही खुला होता है।

आपका Bolt.new ऐप सिर्फ़ अंग्रेज़ी में क्यों है?

क्योंकि इंटरफ़ेस टेक्स्ट आपके components के भीतर लिटरल स्ट्रिंग्स के रूप में बैठा है। जब आप Bolt से प्राइसिंग पेज के लिए प्रॉम्प्ट देते हैं, तो यह <h2>Simple pricing</h2> लिखता है — किसी कैटलॉग के आधार पर लुकअप नहीं। हर हेडिंग, बटन लेबल, empty state, toast और validation message JSX में उसी भाषा में उतरता है जिसमें आपने प्रॉम्प्ट दिया था।

यह Bolt का कोई दोष नहीं है। हर प्रॉम्प्ट-आधारित बिल्डर ऐसा ही करता है, और यह वही पैटर्न है जिसका ज़िक्र हमने Cursor keeps adding hardcoded strings में किया था। मॉडल आपकी माँग के लिए सबसे छोटा सही कोड लिख रहा है, और आपने locale लेयर के लिए नहीं कहा था।

नतीजा यह होता है कि ऐप को किसी सेटिंग्स स्क्रीन में जाकर एडिट करके अनुवादित नहीं किया जा सकता, क्योंकि वहाँ एडिट करने के लिए कुछ है ही नहीं। स्ट्रिंग्स के पास कोई keys नहीं होती।

Bolt.new वास्तव में क्या जनरेट करता है?

एक सामान्य फ्रंट-एंड प्रोजेक्ट, और यह अच्छी खबर है। Bolt React, Next.js, Vite या सामान्य Node आउटपुट बना सकता है, और इसका डिफ़ॉल्ट React पथ एक Vite स्टार्टर है जो React, TypeScript, Tailwind CSS और ESLint लेकर आता है। पूरा टूलचेन StackBlitz WebContainer पर ब्राउज़र में ही चलता है।

स्थानीयकरण के लिहाज़ से सिर्फ़ स्टैक ही अहम फ़ैक्ट है, और वह भी बिल्कुल सामान्य: Vite, React और TypeScript का कॉम्बिनेशन i18n इकोसिस्टम में सबसे ज़्यादा सपोर्टेड है। Lingui, i18next और react-intl — सभी इसे सीधे टारगेट करते हैं। Bolt से जुड़ी कोई भी चीज़ किसी बिल्डर-स्पेसिफ़िक ट्रांसलेशन प्रोडक्ट की माँग नहीं करती।

अगर आपको इसी स्टैक पर किसी दूसरे बिल्डर के लिए वैसा ही वॉकथ्रू चाहिए, तो Lovable Vite i18n में वही वायरिंग बताई गई है।

Bolt प्रोजेक्ट को repository में कैसे लाएँ?

Bolt में पहले से मौजूद इंटीग्रेशन का इस्तेमाल करें। Settings में अपना GitHub अकाउंट कनेक्ट करें, फिर प्रोजेक्ट को किसी नए या मौजूदा repository में पुश करें; यह इंटीग्रेशन कई branches पर काम करने को सपोर्ट करता है, इसलिए आप एक अलग translation branch रख सकते हैं जो आपके मौजूदा काम से अलग हो। इस मामले में Bolt का अपना दस्तावेज़ ही सबसे भरोसेमंद संदर्भ है, और आगे बढ़ने से पहले मौजूदा फ़्लो जाँच लेना अच्छा रहेगा — प्रोडक्ट का यह हिस्सा एक से अधिक बार बदल चुका है।

भाषाओं के बारे में सोचने से पहले यह करने के दो कारण हैं:

1. स्थानीयकरण का काम असल में फ़ाइलों का काम है। कैटलॉग, एक config फ़ाइल, एक provider wrapper और एक switcher component — यह सब tracked फ़ाइलों में होने वाले बदलाव हैं, और इन्हें diff में रिव्यू करना चैट पैनल में पढ़ने से कहीं ज़्यादा आसान है।
2. एक repository पोर्टेबल होती है। इस पूरी कसरत का मक़सद यही है कि आपके अनुवाद आख़िर में वहाँ पहुँचें जिस पर आपका ही नियंत्रण हो।

"डैशबोर्ड के बिना" का असल मतलब क्या है?

इसका मतलब है कि अनुवादित स्ट्रिंग्स आपके repository में फ़ाइलों के रूप में होती हैं, और आपका ऐप उन्हें उसी तरह सर्व करता है जैसे वह किसी भी और asset को सर्व करता है। कोई script tag नहीं, पेज लोड पर कोई external fetch नहीं, और विज़िटर व आपकी कॉपी के बीच कोई वेंडर अकाउंट नहीं।

इसका विकल्प — जो widget मॉडल Weglot और इसी तरह के टूल्स इस्तेमाल करते हैं — पेज लोड होने के बाद उसका अनुवाद करता है। इससे सच में सुविधा मिलती है: आप एक स्निपेट पेस्ट करते हैं और उसी दिन दोपहर तक कुछ न कुछ हो जाता है। लागत बाद में सामने आती है, और वे ठीक करने योग्य नहीं बल्कि संरचनात्मक होती हैं:

• पहली paint source language में होती है, इसलिए swap होने से पहले visitors English देख सकते हैं।
• अनुवादित कॉपी शुरुआती HTML में नहीं होती, जिससे यह कमज़ोर पड़ता है कि सर्च इंजन हर locale के लिए क्या इंडेक्स करते हैं।
• आपके production render path में third-party script मौजूद रहती है।
• आपकी strings vendor के store में रहती हैं, इसलिए वहाँ से निकलने के लिए export करना पड़ता है।

Repo-native स्थानीयकरण की अपनी एक खामी भी है, और इसे साफ़ कहना ही ठीक है: कॉपी में बदलाव का मतलब है एक commit और एक deploy, न कि सिर्फ़ एक save बटन। अगर आपकी टीम लगातार शिप करती है, तो यह कोई बड़ी बात नहीं। लेकिन अगर आपकी मार्केटिंग टीम इंजीनियरिंग की मदद के बिना लाइव कॉपी एडिट करने की उम्मीद रखती है, तो यह एक असली सीमा है।

Repo-native setup कैसे काम करता है?

ऐप में repository कनेक्ट करें। globalize.now कोडबेस को एक बार कन्वर्ट करता है, और यहीं से keys आती हैं — हार्डकोडेड स्ट्रिंग्स कैटलॉग यूनिट बन जाती हैं, और components literals रखने के बजाय एक runtime library से पढ़ना शुरू कर देते हैं। यह कन्वर्शन एक बार होने वाला ऑपरेशन है, कोई ऐसी चीज़ नहीं जो हमेशा दोहराई जाती रहे।

कन्वर्शन के बाद, push jobs आपके ऐप के बढ़ने के साथ नई कैटलॉग यूनिट्स का अनुवाद करते हैं। कोई फ़ीचर जोड़ें, उसकी स्ट्रिंग्स जोड़ें, और नई यूनिट्स का अनुवाद हो जाता है; पुरानी यूनिट्स वैसी ही रहती हैं। कैटलॉग आपके repository में कमिट की गई फ़ाइलों के रूप में वापस आती हैं, आप जिस runtime library पर हैं उसके हिसाब से JSON या PO में, और एक pull request के रूप में पहुँचती हैं जिसे आप किसी भी और बदलाव की तरह रिव्यू करते हैं।

दो सीमाएँ साफ़ शब्दों में कह देना ज़रूरी है, क्योंकि यह श्रेणी अक्सर उलझ जाती है। globalize.now आपकी runtime library की जगह नहीं लेता — i18next, Lingui और next-intl सभी अपना काम करते रहते हैं। और यह DeepL जैसे किसी ट्रांसलेशन इंजन से मुक़ाबला करने वाला प्रोडक्ट भी नहीं है। यह वह लेयर है जो बीच में keys और locale files तैयार करती है। The developer overview में इसकी बारीकियाँ और विस्तार से बताई गई हैं।

क्या यही तरीका Lovable, v0 और Replit पर भी काम करता है?

हाँ, तीन एक जैसी शर्तों के साथ: असली सोर्स कोड, एक Git repository, और एक runtime library जिसे कैटलॉग फ़ीड कर सकें। जो भी बिल्डर एक सामान्य फ्रंट-एंड प्रोजेक्ट जनरेट करता है, वह इसके लिए योग्य है। इनमें फ़र्क़ सिर्फ़ इस बात का है कि आप कोड कैसे बाहर निकालते हैं।

हमारी तरफ़ से Lovable के लिए सबसे विकसित रास्ता मौजूद है, जिसमें एक इन-एडिटर रूट भी शामिल है — the Lovable integration page इसे कवर करता है, और वहाँ लिखी गई ज़्यादातर बातें बिना किसी बदलाव के Bolt पर भी लागू होती हैं। अगर आप अभी किसी एक बिल्डर पर टिके नहीं हैं और अलग-अलग बिल्डर आज़मा रहे हैं, तो the vibe coders overview शुरुआत के लिए बेहतर जगह है।

अगर आप Lovalingo इस्तेमाल कर रहे थे, तो क्या?

Lovalingo अगस्त 2026 के अंत में बंद हो गया और उसकी साइट भी अब मौजूद नहीं है, इसलिए जिस किसी ने भी उसके ज़रिए Bolt या Lovable ऐप को स्थानीयकृत किया था, उसे अब उन स्ट्रिंग्स के लिए एक नई जगह चाहिए। यह एक नया सेटअप नहीं बल्कि माइग्रेशन है: पहले एक्सपोर्ट करें, फिर कन्वर्ट करें। The migration guide इसे स्टेप-बाय-स्टेप बताता है, और the comparison page यह बताता है कि जब अनुवाद किसी होस्टेड सर्विस से आपके repository में शिफ़्ट होते हैं तो क्या बदलता है।

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

दूसरी भाषा जोड़ने से पहले आपको क्या जाँचना चाहिए?

पहली कैटलॉग बनने से पहले इन बातों को जाँच लें, क्योंकि हर आइटम को अभी ठीक करना पाँच भाषाओं के लाइव हो जाने के बाद ठीक करने से कहीं सस्ता है:

• Concatenated strings। "Welcome back, " + name को translator अपनी ज़रूरत के अनुसार reorder नहीं कर सकता। इसके बजाय interpolation का इस्तेमाल करें।
• बहुवचन (Plurals)। अंग्रेज़ी में दो रूप हैं। पोलिश में तीन, अरबी में छह। count === 1 पर लगाया गया एक साधारण ternary ज़्यादातर भाषाओं में गलत साबित होगा।
• Dates, numbers और currency। String formatting के बजाय Intl का इस्तेमाल करें।
• लेआउट। जर्मन अंग्रेज़ी से लंबी होती है; फ़िक्स्ड-विड्थ बटन टूट जाते हैं। Tailwind में इसे नज़रअंदाज़ करना आसान होता है क्योंकि बिल्ड टाइम पर क्लासेज़ ठीक ही दिखती हैं।
• Right-to-left। अगर roadmap में अरबी या हिब्रू है, तो अभी निर्णय लें—RTL को बाद में retrofit करना सबसे महँगा पड़ता है।

इन सभी की pricing प्रति workspace है; per-seat और per-language charges नहीं हैं। इसलिए भाषाओं की संख्या budget का नहीं, product का निर्णय है। मौजूदा आँकड़े pricing page पर उपलब्ध हैं।

कहाँ से शुरुआत करें

अगर आपका Bolt प्रोजेक्ट पहले से ही GitHub पर है, तो अगला कदम उस repository के आधार पर एक कन्वर्शन है, न कि किसी टूलिंग के बारे में फ़ैसला। अगर वह अभी तक GitHub पर नहीं है, तो यही इससे पहले वाला कदम है।