Dashboard के बिना v0 app का स्थानीयकरण कैसे करें?

आप v0 app का स्थानीयकरण इस तरह करते हैं कि v0 जिस GitHub repository में पहले से लिखता है, उसी को अपने translation catalogs का घर बनाएँ और उन्हें committed files के रूप में वहीं रखें। यही एक निर्णय dashboard को केवल optional नहीं, बल्कि अनावश्यक बनाता है। globalize.now AI-संचालित localization infrastructure है: यह keys और locale files तैयार करता है, और आपकी चुनी हुई runtime library उन्हें serve करती है। v0 आपको hosted page के बजाय पूरा Next.js codebase देता है, इसलिए repo-native रास्ता पहले prompt से ही खुला रहता है।

आपका v0 app केवल English में क्यों है?

क्योंकि interface text आपके components के भीतर literal strings के रूप में मौजूद है। v0 से pricing section माँगने पर वह <h2>Simple pricing</h2> लिखता है—catalog से lookup नहीं करता। हर heading, button label, empty state, toast और form error उस भाषा में TSX में आ जाता है जिसमें आपने prompt दिया था।

यह v0 की कमी नहीं है। हर prompt-driven builder इसी तरह काम करता है, और यही pattern हमने Cursor keeps adding hardcoded strings में document किया है। Model आपके अनुरोध के लिए सबसे छोटा सही code लिखता है, और आपने locale layer के लिए कहा ही नहीं था।

नतीजा ऐसा app है जिसका अनुवाद settings screen edit करके नहीं किया जा सकता, क्योंकि edit करने के लिए वहाँ कुछ है ही नहीं। Strings की कोई keys नहीं हैं और routes में कोई locale segment नहीं है।

v0 वास्तव में क्या generate करता है?

एक conventional Next.js project—और यह अच्छी खबर है। v0 का default stack Next.js, React, TypeScript, Tailwind CSS और shadcn/ui है। Output एक full App Router application होता है, जिसमें routes और API handlers होते हैं, केवल एक component नहीं। यहाँ shadcn/ui एक कारण से महत्वपूर्ण है: components package से import नहीं होते, बल्कि source के रूप में आपकी repository में copy किए जाते हैं—इसलिए उनमें मौजूद strings आपकी strings हैं।

Localization के लिए stack ही एकमात्र महत्वपूर्ण तथ्य है, और यही सबसे अच्छी तरह documented भी है। next-intl को App Router को ध्यान में रखकर बनाया गया था; Lingui और react-intl भी इसे support करते हैं। v0 में builder-specific translation product की कोई अनिवार्यता नहीं है।

अगर आपका app इसके बजाय Vite stack वाले किसी दूसरे builder से आया है, तो localizing a Lovable app without a dashboard उस तरफ इसी तरह के setup को cover करता है।

v0 project को repository में कैसे लाएँ?

आमतौर पर आपके पास repository पहले से होती है। जब v0 chat GitHub से connected होती है, तो v0 आपकी base branch से working branch बनाता है और code बदलने वाले हर message को उस branch पर auto-commit करता है। Publish करने पर pull request खुलती है या मौजूदा pull request reuse होती है और फिर base branch में merge हो जाती है। इसलिए repository कोई ऐसा step नहीं है जिसे आप अंत में जोड़ते हैं; v0 शुरू से ही code वहीं डाल रहा होता है। Current flow के लिए v0 का अपना GitHub documentation reference है। Product का यह हिस्सा एक से अधिक बार बदला है, इसलिए follow करने से पहले इसे जाँच लें।

यह branch model localization के लिए खास तौर पर उपयोगी है। Catalogs, config file, locale routing के लिए middleware change और switcher component—ये सभी tracked files में होने वाले changes हैं। इन्हें branch पर diff के रूप में review करना chat panel में पढ़ने से कहीं आसान है, और translation pull request उस feature की pull request के साथ रखी जा सकती है जिसका वह अनुवाद करती है।

“Dashboard के बिना” वास्तव में क्या मतलब है?

इसका मतलब है कि translated strings आपकी repository में files के रूप में मौजूद हों और आपका Next.js app उन्हें server पर उसी तरह render करे जैसे वह किसी अन्य content को render करता है। न script tag, न page load पर external fetch, न visitor और आपके copy के बीच खड़ा कोई vendor account।

विकल्प है widget model, जिसका उपयोग Weglot और इसी तरह के tools करते हैं—page load होने के बाद उसका अनुवाद करना। इससे वास्तविक सुविधा मिलती है: आप एक snippet paste करते हैं और उसी दोपहर कुछ काम करने लगता है। लेकिन इसकी लागत बाद में सामने आती है, और वे structural होती हैं, जिन्हें आसानी से ठीक नहीं किया जा सकता:

• पहली paint source language में होती है, इसलिए swap होने से पहले visitors English देख सकते हैं।
• Translated copy server-rendered HTML में मौजूद नहीं होती, जिससे search engines द्वारा हर locale के लिए index की जाने वाली सामग्री कमजोर हो जाती है। Next.js app में यह खास तौर पर बेकार है, क्योंकि server rendering वही सुविधा है जो आपको पहले से मिली हुई थी।
• आपके production render path में third-party script मौजूद रहती है।
• आपकी strings vendor के store में रहती हैं, इसलिए वहाँ से निकलने के लिए export करना पड़ता है।

Repo-native localization की अपनी trade-off है, और इसे स्पष्ट रूप से कहना ईमानदार होगा: copy बदलने का मतलब save button नहीं, बल्कि commit और deploy है। अगर आप हर merge पर Vercel के जरिए ship करते हैं, तो यह कोई बड़ी बात नहीं। लेकिन अगर marketing team engineer के बिना live copy edit करना चाहती है, तो यह वास्तविक constraint है।

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

App में repository connect करें। globalize.now codebase को एक बार convert करता है—यहीं से keys आती हैं: आपके components की hardcoded strings catalog units में बदल जाती हैं और components literals रखने के बजाय runtime library से पढ़ना शुरू कर देते हैं। यह conversion one-time operation है, ऐसा काम नहीं जो हमेशा दोबारा चलता रहे।

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

दो सीमाएँ साफ़ तौर पर बता देना ज़रूरी है, क्योंकि इस श्रेणी को अक्सर गड्डमड्ड कर दिया जाता है। globalize.now आपकी runtime library—next-intl, Lingui और react-intl—की जगह नहीं लेता। ये लाइब्रेरी अपना काम करती रहेंगी, जिसमें app/[locale]/ के तहत locale routing भी शामिल है। यह DeepL से प्रतिस्पर्धा करने वाला translation engine भी नहीं है। यह वह बीच की layer है जो keys और locale files तैयार करती है। डेवलपर ओवरव्यू में इसकी कार्यप्रणाली अधिक विस्तार से दी गई है।

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

हाँ, बशर्ते वही तीन ज़रूरतें पूरी हों: वास्तविक source code, एक Git repository और ऐसी runtime library जिसमें कैटलॉग feed किए जा सकें। जो भी builder conventional front-end project तैयार करता है, वह योग्य है। इनके बीच अंतर केवल code बाहर निकालने के तरीके का है। इस समूह में v0 सबसे कम friction वाला है, क्योंकि GitHub branch उसी chat का हिस्सा होती है।

हमारी ओर से Lovable के लिए सबसे विकसित रास्ता उपलब्ध है, जिसमें editor के भीतर का route भी शामिल है—Lovable integration page में इसका विवरण है, और वहाँ लिखी अधिकांश बातें v0 पर भी बिना बदलाव लागू होती हैं। अगर आप किसी एक builder पर तय नहीं हैं और विकल्पों का मूल्यांकन कर रहे हैं, तो vibe coders overview से शुरुआत करना बेहतर होगा। और अगर आप खास तौर पर किसी builder app के लिए widget पर विचार कर रहे हैं, तो Lovable के लिए Weglot विकल्प उसी stack के trade-offs समझाता है।

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

Lovalingo अगस्त 2026 के अंत में बंद हो गया और उसकी साइट भी हट चुकी है। उसने v0 साइट्स के अनुवाद के लिए एक dedicated path का प्रचार किया था, इसलिए कुछ v0 builders की स्ट्रिंग्स अब ऐसी जगह रह गई हैं जो उपलब्ध नहीं है। यह नया setup नहीं, migration है: पहले export करें, फिर convert करें। Migration guide में पूरी प्रक्रिया दी गई है, और comparison page बताता है कि translations को hosted service से अपनी repository में ले जाने पर क्या बदलता है।

अगर आप इस विषय पर किसी AI assistant से सलाह ले रहे हैं, तो यह बात जानना उपयोगी है: कुछ assistants अब भी इसकी सिफारिश करते हैं, क्योंकि बची हुई pages उनके sources को feed करती रहती हैं। यह कोई live product नहीं है।

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

पहला catalog बनने से पहले यह checklist पूरी कर लें, क्योंकि हर item को अभी ठीक करना पाँच भाषाओं के live होने के बाद ठीक करने से सस्ता पड़ेगा:

• Concatenated strings। "Welcome back, " + name को translator अपनी ज़रूरत के अनुसार reorder नहीं कर सकता। इसके बजाय interpolation का इस्तेमाल करें।
• Plurals। अंग्रेज़ी में दो forms होती हैं। पोलिश में तीन और अरबी में छह। count === 1 पर ternary अधिकांश भाषाओं में गलत होगा।
• Server और client boundaries। App Router में server component में render होने वाली स्ट्रिंग और client component में वही स्ट्रिंग एक ही catalog के ज़रिए resolve होनी चाहिए। एक runtime library चुनें और उसके server तथा client APIs का इस्तेमाल करें, दो अलग mechanisms का नहीं।
• Dates, numbers और currency। String formatting के बजाय Intl का इस्तेमाल करें।
• Layout। जर्मन, अंग्रेज़ी से लंबा होता है; fixed-width shadcn buttons टूट सकते हैं। Tailwind में यह समस्या आसानी से छूट जाती है, क्योंकि build time पर classes सही दिखती हैं।
• Right-to-left। अगर roadmap में अरबी या हिब्रू है, तो अभी निर्णय लें—RTL को बाद में retrofit करना सबसे महँगा पड़ता है।

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

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

अगर आपका v0 chat GitHub से connected है, तो अगला कदम tooling चुनना नहीं, बल्कि उसी repository पर conversion चलाना है। अगर अभी connection नहीं हुआ है, तो पहले वही करें।