बिना dashboard के Replit app को multilingual कैसे बनाएँ?

आप किसी Replit app को multilingual बनाते हैं उसकी Git repository को GitHub से connect करके और translation catalogs को उस repository में committed files के रूप में रखकर। Replit हर Agent checkpoint को पहले से ही एक Git commit के रूप में स्टोर करता है, इसलिए भाषाओं के बारे में सोचने से पहले ही repository मौजूद होती है; असल काम है इसे GitHub पर लाना और catalogs को उसी history के ज़रिए वापस आने देना। globalize.now एक AI-powered localization infrastructure है: यह keys और locale files तैयार करता है, और जो runtime library आपका app पहले से इस्तेमाल कर रहा है, वही उन्हें सर्व करती है। Runtime path में कोई dashboard नहीं होता, और page लोड होने के बाद कुछ भी translate नहीं होता।

Agent से app को translate करने के लिए कहना काम क्यों नहीं करता?

क्योंकि translate करने के लिए कुछ भी होता ही नहीं। जब आप Replit Agent से एक dashboard के लिए prompt देते हैं, तो वह component में <h2>Your bookings</h2> लिखता है, किसी catalog के खिलाफ़ lookup नहीं। हर heading, बटन, empty state, toast और validation error, JSX में उस भाषा के literal टेक्स्ट के रूप में जाता है जिसमें आपने prompt लिखा था।

इसलिए जब आप बाद में Agent से "app को Afrikaans में translate कर दो" कहते हैं, तो आपको दो आधे-अधूरे नतीजों में से एक मिलता है: components की एक दूसरी copy जिसमें टेक्स्ट बदल दिया गया है, या फिर एक hand-rolled translations object जो सिर्फ़ उन screens को कवर करता है जिन्हें Agent ने देखा था। इनमें से कोई भी locale layer नहीं है। आगे आने वाला feature फिर से English में ही शिप होता है। हमने यही दोहराव Cursor keeps adding hardcoded strings में भी दर्ज किया है; Replit Agent का व्यवहार भी अलग नहीं है, क्योंकि यह सामने रखे prompt को हल करता है, उसके पीछे की architecture को नहीं।

इसका समाधान structural है: strings को keys दें, translations को files में रखें, और runtime को उन files से पढ़ने दें। एक codebase में "multilingual" का यही मतलब होता है, और यह एक-बार होने वाला बदलाव है।

Replit Agent असल में क्या जेनरेट करता है?

एक पारंपरिक web project, जो एक अच्छी खबर है। Replit के curated app types front end पर React और ShadCN UI के इर्द-गिर्द बने होते हैं, आम तौर पर उसी project में Express server के साथ, सब कुछ TypeScript में। सितंबर 2025 से Agent किसी भी framework पर भी काम करता है जो आप खुद लाएँ, imported GitHub repositories सहित, इसलिए Next.js या Vue project भी संभव है; डिफ़ॉल्ट रास्ता अब भी React stack ही है।

Localization के लिए, stack ही एकमात्र बात है जो अहमियत रखती है, और यह एक standard आधार है। React, Vite और TypeScript का combination i18n ecosystem में सबसे ज़्यादा सपोर्टेड combination है: i18next, Lingui और react-intl — सभी इसे सीधे target करते हैं। अगर Agent ने आपके लिए इसके बजाय एक Next.js app बनाया है, तो चुनाव next-intl, react-i18next और Lingui के बीच होता है, और that comparison एक अलग post में है।

किसी सिर्फ़ front-end वाले builder से जो अलग है, वह है project का दूसरा आधा हिस्सा। एक Replit app में आम तौर पर एक server होता है, और servers में भी strings होते हैं। इस पर आगे बात करते हैं।

Replit app में Git repository कहाँ होती है?

यह पहले से ही मौजूद है। Replit का version control अंदर से Git ही है, और Agent checkpoints उस repository में commits होते हैं। जब भी Agent किसी feature को पूरा करके आपको एक rollback point देता है, तब वह असल में commit कर चुका होता है। Replit का अपना documentation यह सलाह देता है कि जब आप external repositories के साथ काम करें, तो long-term tracking के लिए सामान्य Git commits पर स्विच करें — और यहाँ ठीक यही स्थिति है।

इसे GitHub पर लाने के लिए:

1. Project editor के Tools section से Git tool जोड़ें।
2. Connected services के अंतर्गत अपना GitHub account connect करें, फिर Git pane से repository connect करें। अगर project पहले कभी initialise नहीं हुआ है, तो pane पहले वही करने का सुझाव देगा।
3. Push करें। Pane एक क्लिक में push करता है, और यह उन सब चीज़ों के साथ sync रहता है जो आप Shell में चलाते हैं, इसलिए git push origin main भी काम करता है।

Replit GitLab और Bitbucket को भी सपोर्ट करता है, और वही flow लागू होता है। असल बात provider की नहीं है; बात यह है कि repository अब किसी ऐसी जगह मौजूद है जहाँ एक localization job उसके खिलाफ़ pull request खोल सकती है।

किसी भी string को छूने से पहले यह कर लें। Localization का काम file का काम है, और एक diff ही उसे review करने की सही जगह है।

एक Replit app के लिए "बिना dashboard के" का मतलब क्या है?

इसका मतलब है कि translated strings repository में files हैं और app उन्हें किसी अन्य asset की तरह ही सर्व करता है। कोई script tag नहीं, page load पर कोई external fetch नहीं, visitor और आपकी copy के बीच कोई vendor account नहीं।

इसका विकल्प एक runtime widget है जो page paint होने के बाद टेक्स्ट बदल देता है। इसकी लागत structural है: पहला paint English में होता है, translated copy उस HTML में नहीं होती जिसे crawlers पहले पढ़ते हैं, एक third-party script आपके production path में बैठा रहता है, और आपकी strings vendor के store में रहती हैं, इसलिए वहाँ से निकलने का मतलब है एक export। इस दलील का Lovable version Localize a Lovable app without a dashboard में है और वैसे ही Replit पर भी लागू होता है।

एक Replit-विशिष्ट वजह है जिससे यह यहाँ और भी ज़्यादा अहम हो जाता है। Replit आपके लिए app को deploy करता है, इसलिए आपके Replit domain पर चल रही copy वही होती है जो deploy के समय project में मौजूद थी। एक widget उस deployment को बाहर से translate करता। Repository में मौजूद catalogs का मतलब है कि deployment में पहले से ही हर भाषा शामिल होती है, और Replit preview शिप करने से पहले ही आपको German version दिखा देता है।

यह trade-off असली है और इसे साफ़ कहना ज़रूरी है: copy में बदलाव का मतलब है एक commit और एक redeploy, कोई save बटन नहीं। Replit से solo शिप करने वाले किसी builder के लिए यह कोई मुद्दा ही नहीं है; लेकिन जो कोई project को छुए बिना live copy edit करने की उम्मीद रखता है, उसके लिए यह एक सीमा है।

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

globalize.now ऐप में रिपॉज़िटरी कनेक्ट करें। कोडबेस पर कन्वर्शन एक बार चलता है: हार्डकोडेड स्ट्रिंग्स कैटलॉग यूनिट्स में बदल जाती हैं जिनकी अपनी keys होती हैं, और कॉम्पोनेंट्स literals रखने के बजाय एक रनटाइम लाइब्रेरी से पढ़ना शुरू कर देते हैं। यह एक बार होने वाली प्रक्रिया है, ऐसा कुछ नहीं जो बाद में फिर से चलता है।

कन्वर्शन के बाद, जैसे-जैसे ऐप बढ़ता है, पुश जॉब्स नए कैटलॉग यूनिट्स का अनुवाद करती हैं। Agent से एक नया सेटिंग्स पेज बनाने को कहें, पुश करें, और नए यूनिट्स का अनुवाद हो जाता है; मौजूदा यूनिट्स जैसे थे वैसे ही बने रहते हैं। कैटलॉग्स कमिटेड फ़ाइलों के रूप में वापस आते हैं, रनटाइम लाइब्रेरी के अनुसार JSON या PO, एक पुल रिक्वेस्ट में जिसे आप किसी भी अन्य बदलाव की तरह रिव्यू कर सकते हैं।

दो सीमाएँ हैं, क्योंकि यह श्रेणी अक्सर गड़बड़ा जाती है। globalize.now रनटाइम लाइब्रेरी की जगह नहीं लेता; i18next, Lingui और next-intl अपना काम करते रहते हैं। और यह DeepL जैसे ट्रांसलेशन इंजन से प्रतिस्पर्धा भी नहीं करता। यह बीच की वह लेयर है जो keys और locale files बनाती है। डेवलपर ओवरव्यू में इसकी पूरी मैकेनिक्स दी गई है।

अनुवाद वापस Replit में कैसे आते हैं?

उसी Git पैनल के ज़रिए, बस दूसरी दिशा में। यह वह स्टेप है जो Bolt या Lovable से अलग है, क्योंकि Replit वही जगह भी है जहाँ ऐप चलता है।

1. GitHub पर पुल रिक्वेस्ट को रिव्यू करें और मर्ज करें।
2. Replit के Git पैनल में, Pull चुनें। अगर इस दौरान आपने या Agent ने वही फ़ाइलें बदली हैं, तो पैनल कॉन्फ़्लिक्ट्स हाइलाइट कर देता है और आप मर्ज पूरा करने से पहले उन्हें एडिटर में सुलझा सकते हैं।
3. रीडिप्लॉय करें। कैटलॉग्स अब प्रोजेक्ट का हिस्सा हैं, इसलिए डिप्लॉयमेंट हर भाषा को साथ लेकर चलता है।

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

कौन-सी स्ट्रिंग्स सर्वर पर रहती हैं?

वे जिन्हें फ्रंट एंड कभी JSX के रूप में देखता ही नहीं। जिस Replit ऐप में Express बैक एंड होता है, उसमें स्ट्रिंग्स की एक दूसरी परत भी होती है: API एरर मैसेज, वेलिडेशन रेस्पॉन्स, ईमेल सब्जेक्ट, नोटिफिकेशन का कंटेंट, CSV हेडर्स, यानी वह सब कुछ जिसे सर्वर भेजने से पहले फ़ॉर्मेट करता है। फ्रंट-एंड कैटलॉग वहाँ तक नहीं पहुँच पाता, और कोई विजेट तो इन्हें बिल्कुल भी नहीं देख सकता, क्योंकि ये कभी DOM में ही नहीं आते।

पैटर्न वही है जो क्लाइंट में इस्तेमाल होता है, सिर्फ इसे सर्वर-साइड पर लागू करना होता है। सर्वर को रनटाइम लाइब्रेरी की एक कॉपी दें, रिक्वेस्ट से विज़िटर की locale पढ़ें (एक Accept-Language हेडर या यूज़र रेकॉर्ड में locale फ़ील्ड), और रेस्पॉन्स को स्ट्रिंग literals के बजाय कैटलॉग से फ़ॉर्मेट करें। key नेमस्पेस साझा रहता है, इसलिए errors.booking.overlap का मतलब टोस्ट मैसेज में भी वही होता है जो 409 रेस्पॉन्स में होता है।

अगर इसे छोड़ दिया, तो ऐप पहली एरर तक बहुभाषी दिखेगा, फिर अंग्रेज़ी में बोलने लगेगा।

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

कन्वर्शन से पहले इन बातों की जाँच कर लें, क्योंकि हर एक को अभी ठीक करना पाँच भाषाएँ लाइव होने के बाद ठीक करने से बहुत सस्ता है:

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

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

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

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