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

आप Base44 ऐप को Base44 द्वारा दिए गए two-way sync से GitHub से जोड़कर और ट्रांसलेशन कैटलॉग को उस रिपॉज़िटरी में कमिटेड फ़ाइलों के रूप में रखकर स्थानीयकृत करते हैं। Base44 पहले से ही एडिटर और रिपॉज़िटरी के बीच हर बदलाव को मिरर करता है, इसलिए जैसे ही locale फ़ाइलें main ब्रांच पर आती हैं वे ऐप का हिस्सा बन जाती हैं। globalize.now एक AI-संचालित स्थानीयकरण इन्फ्रास्ट्रक्चर है: यह कीज़ और locale फ़ाइलें बनाता है, और आपके प्रोजेक्ट में मौजूद रनटाइम लाइब्रेरी उन्हें सर्व करती है। रनटाइम पथ में कोई डैशबोर्ड नहीं होता, और पेज लोड होने के बाद कुछ भी उसे ट्रांसलेट नहीं करता।

आपका Base44 ऐप केवल अंग्रेज़ी में क्यों है?

क्योंकि इंटरफ़ेस टेक्स्ट आपके कंपोनेंट्स के अंदर लिटरल स्ट्रिंग्स के रूप में बैठा है। जब आप Base44 से बुकिंग्स पेज माँगते हैं, तो यह <h2>Your bookings</h2> को एक React कंपोनेंट में लिखता है, किसी कैटलॉग के खिलाफ़ लुकअप नहीं करता। हर हेडिंग, बटन लेबल, खाली स्टेट, टोस्ट और वैलिडेशन मैसेज उसी भाषा में JSX में उतरता है जिसमें आपने प्रॉम्प्ट दिया था।

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

Base44 से "ऐप को जर्मन में ट्रांसलेट करो" कहना भी इसे ठीक नहीं करता। आपको उन स्क्रीन्स की जर्मन कॉपी मिलती है जिन्हें मॉडल ने जाँचा था, या एक छोटा स्ट्रिंग्स ऑब्जेक्ट जिसे उसने तुरंत गढ़ लिया। अगला प्रॉम्प्ट फिर से अंग्रेज़ी में नया टेक्स्ट लिखता है, क्योंकि प्रोजेक्ट में कहीं यह नहीं लिखा कि टेक्स्ट को कैटलॉग से होकर गुज़रना है।

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

Vite से बना एक मानक React प्रोजेक्ट। Base44 के अपने प्रोजेक्ट-संरचना दस्तावेज़ Code टैब और किसी जुड़ी हुई रिपॉज़िटरी में मिलने वाला लेआउट दिखाते हैं: src/pages में हर रूट के लिए एक फ़ाइल होती है, इसलिए Home.jsx, / बन जाता है और Settings.jsx, /settings बन जाता है; src/components में पुन: उपयोग योग्य हिस्से रहते हैं जिसमें पहले से बने कंपोनेंट्स का ui/ फ़ोल्डर होता है; src/api, src/hooks, src/lib और src/utils में SDK क्लाइंट, हुक्स और हेल्पर्स रहते हैं।

स्थानीयकरण के लिए बाकी सबकी तुलना में दो डायरेक्टरीज़ ज़्यादा मायने रखती हैं। functions/ में आपका बैकएंड लॉजिक रहता है, हर फ़ंक्शन के लिए एक TypeScript फ़ाइल, और ये फ़ाइलें वह टेक्स्ट फ़ॉर्मेट करती हैं जो यूज़र पढ़ते हैं: एरर रिस्पॉन्स, ईमेल, जनरेट किए गए दस्तावेज़। entities/ में आपका डेटा मॉडल JSON schema फ़ाइलों के रूप में रहता है, और two-way sync के तहत entities रिपॉज़िटरी में नहीं बल्कि Base44 में ही मैनेज होती हैं।

तो Base44 ऐप में दो स्ट्रिंग सतहें होती हैं जिन्हें कैटलॉग कवर कर सकते हैं — React क्लाइंट और बैकएंड फ़ंक्शंस — और एक जिसे नहीं कर सकते, entities के अंदर का डेटा। यह आख़िरी बिंदु आगे फिर से आएगा।

आप Base44 ऐप को रिपॉज़िटरी में कैसे लाते हैं?

Base44 यह कनेक्शन खुद देता है। एडिटर में, Dashboard खोलें, GitHub आइकन पर क्लिक करें, और कनेक्ट करें। आप अपने GitHub अकाउंट या ऑर्गनाइज़ेशन पर Base44 Builder ऐप को अनुमति देते हैं, यह चुनते हैं कि यह किन रिपॉज़िटरीज़ तक पहुँच सकता है, और ऐप के लिए एक नई रिपॉज़िटरी बनाते हैं। इसके बाद रिपॉज़िटरी और एडिटर दोनों दिशाओं में सिंक रहते हैं।

Base44 के दस्तावेज़ों के दो नियम आगे की सारी बातें तय करते हैं। पहला, sync अपने-आप होता है: Base44 में आप जो भी बदलाव करते हैं, यहाँ तक कि AI द्वारा किसी प्रॉम्प्ट से किए गए बदलाव भी, बिना किसी push स्टेप के रिपॉज़िटरी में कमिट हो जाते हैं, और मैन्युअल रूप से push करने के लिए कोई बटन नहीं है। दूसरा, वापसी का रास्ता main ब्रांच है। main में मर्ज हुई कोई भी चीज़ Base44 ऐप में दिखाई देती है, और master या कोई और डिफ़ॉल्ट ब्रांच नाम सपोर्टेड नहीं है। मर्ज के बाद आप Publish पर क्लिक करके नए वर्ज़न को यूज़र्स के लिए लाइव करते हैं।

Two-way sync के लिए Builder प्लान या उससे ऊपर का प्लान चाहिए, और केवल ऐप का मालिक ही शुरुआती कनेक्शन बना सकता है। अगर आपके अकाउंट ने पुराना one-way Export to GitHub इंटीग्रेशन सेटअप किया है, तो GitHub पैनल में उसे डिस्कनेक्ट करके two-way sync से फिर से जोड़ने का एक लिंक होता है; one-way रास्ता कभी भी कुछ वापस एडिटर में नहीं लाता, जबकि स्थानीयकरण के लिए ठीक यही दिशा चाहिए।

लोकल काम के लिए, रिपॉज़िटरी क्लोन करें, npm install चलाएँ, Base44 CLI इंस्टॉल करें, फिर base44 login और base44 link चलाकर क्लोन को उसके ऐप से जोड़ें। base44 dev फ्रंटएंड को लोकल बैकएंड के खिलाफ़ चलाता है। आपकी लोकल ब्रांच को main में मर्ज करना ही उसे वापस sync करता है।

Base44 ऐप के लिए "बिना डैशबोर्ड के" का क्या मतलब है?

इसका मतलब है कि ट्रांसलेट की गई स्ट्रिंग्स कभी किसी होस्टेड सर्विस में नहीं रहतीं जिसे आपके ऐप को कॉल करना पड़े या जहाँ से आपको एक्सपोर्ट करना पड़े। वे src/locales/de.json के बगल में src/pages/Home.jsx में रहती हैं, उन्हीं कमिट्स में वर्ज़न होती हैं, उन्हीं pull requests में रिव्यू होती हैं, और उसी Publish क्लिक से डिप्लॉय होती हैं।

इसके विकल्पों में से हर एक की कुछ खास कीमत Base44 पर चुकानी पड़ती है। ब्राउज़र में पेज को ट्रांसलेट करने वाला एक रनटाइम विजेट सोर्स को छुए बिना छोड़ देता है, इसलिए रिपॉज़िटरी अब भी कहती है कि ऐप अंग्रेज़ी में है, और हर विज़िटर को लोड पर ट्रांसलेशन की देरी झेलनी पड़ती है। अपने खुद के एडिटर वाला एक होस्टेड ट्रांसलेशन टूल असली डेटा रिपॉज़िटरी के बाहर रखता है, इसलिए Base44 ने जो two-way sync बनाया है वह ऐसे कोडबेस को सिंक कर रहा होता है जिसमें भाषाएँ होती ही नहीं। दोनों ही आपके और उस टेक्स्ट के बीच, जो पहले से ही आपकी अपनी फ़ाइलों में मौजूद है, एक दूसरा सिस्टम खड़ा कर देते हैं।

Repo-native तरीका sync का वैसे ही इस्तेमाल करता है जैसे उसे डिज़ाइन किया गया था। कैटलॉग फ़ाइलें हैं। फ़ाइलें कमिट होती हैं। कमिटेड फ़ाइलें main तक पहुँचती हैं। main एडिटर तक पहुँचता है। यही पूरी पाइपलाइन है, और इसमें से कुछ भी स्थानीयकरण के लिए विशेष नहीं है।

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

the app में रिपॉज़िटरी कनेक्ट करें और conversion को एक बार चलाएँ। यह conversion आपके कंपोनेंट्स और बैकएंड फ़ंक्शंस में मौजूद लिटरल स्ट्रिंग्स को ढूँढता है, उन्हें कीज़ देता है, अगर प्रोजेक्ट में कोई रनटाइम लाइब्रेरी नहीं है तो i18next या Lingui जैसी कोई एक जोड़ता है, और आपकी रिपॉज़िटरी पर सोर्स कैटलॉग और शुरुआती टार्गेट भाषाओं के साथ एक pull request खोलता है। वही pull request पूरा हैंडओवर है। इसे GitHub पर किसी भी दूसरे बदलाव की तरह रिव्यू करें, main में मर्ज करें, और Base44 इसे एडिटर में मिरर कर देता है।

इसके बाद, push jobs नए कैटलॉग यूनिट्स को ट्रांसलेट करते हैं। जब आप Base44 से कोई नया फ़ीचर माँगते हैं और sync उसे कमिट कर देता है, तो सोर्स कैटलॉग में मौजूद कोई भी नई कीज़ ट्रांसलेट होकर pull request के रूप में डिलीवर हो जाती हैं। उसे मर्ज करें, Publish पर क्लिक करें, और वह फ़ीचर हर भाषा में लाइव हो जाता है। आपकी प्रॉम्प्टिंग की आदतों में कुछ भी बदलने की ज़रूरत नहीं, और आपका ऐप रनटाइम पर किसी बाहरी सर्विस को कॉल नहीं करता।

यही तरीका Lovable, Bolt, v0 और Replit पर भी काम करता है, और मैकेनिक्स बिल्कुल एक जैसे हैं क्योंकि ये चारों आपको एक पारंपरिक फ्रंट-एंड प्रोजेक्ट थमाते हैं। Lovable वॉकथ्रू में कैटलॉग संरचना पर सबसे ज़्यादा विवरण है, Bolt गाइड उस बिल्डर के लिए एक्सपोर्ट स्टेप कवर करता है जिसमें नेटिव sync नहीं है, और Lovable के क्लासिक स्टैक के लिए Vite गाइड कोड स्तर पर Base44 के React और Vite आउटपुट से सबसे मेल खाता है। अगर आप किसी एक बिल्डर पर पक्के तौर पर टिकने के बजाय बिल्डर्स की तुलना कर रहे हैं, तो वाइब कोडर्स ओवरव्यू बेहतर शुरुआती बिंदु है।

बैकएंड फ़ंक्शंस में कौन-सी स्ट्रिंग्स रहती हैं?

वह सब कुछ जो कोई यूज़र पढ़ता है और जो सर्वर-साइड पर बनता है। किसी फ़ंक्शन से लौटाया गया वैलिडेशन एरर, उसके भेजे गए ईमेल की सब्जेक्ट लाइन, उसके जनरेट किए PDF का बॉडी, किसी नोटिफ़िकेशन का टेक्स्ट। ये स्ट्रिंग्स कभी JSX के रूप में नहीं दिखतीं, इसलिए फ्रंट-एंड कैटलॉग में ये नहीं होतीं और एक रनटाइम विजेट इन्हें नहीं देख सकता।

पैटर्न वही है जो क्लाइंट पर है। आने वाले रिक्वेस्ट से माँगी गई locale पढ़ें, फ़ंक्शन साइड पर उस locale के लिए कैटलॉग लोड करें, और key namespace को क्लाइंट के साथ साझा करें ताकि किसी मैसेज का मतलब UI में और API रिस्पॉन्स में एक जैसा रहे। चूँकि functions/ डायरेक्टरी रिपॉज़िटरी में है, conversion इन फ़ाइलों को किसी भी और सोर्स फ़ाइल की तरह ही मानता है और कैटलॉग इनके साथ बैठते हैं।

Entities के अंदर की कंटेंट का क्या?

यह Base44 की खास सीमा है। Entities आपका डेटा मॉडल हैं, जो Base44 के अंदर मैनेज होती हैं, और two-way sync के तहत ये रिपॉज़िटरी का हिस्सा नहीं होतीं। प्रोडक्ट नाम, सर्विस डिस्क्रिप्शन या किसी हेल्प आर्टिकल जैसा रिकॉर्ड डेटा है, इंटरफ़ेस टेक्स्ट नहीं, और इसे कोई कैटलॉग कभी नहीं समेटेगा।

डेटा कंटेंट को entity पर ही एक भाषा-आयाम चाहिए होता है: एक locale फ़ील्ड, या हर भाषा के लिए अलग फ़ील्ड, और ऐसी क्वेरीज़ जो विज़िटर की locale पढ़ें। यह सेटअप वही है जिसे हम Lovable ऐप्स में डेटाबेस कंटेंट के लिए बताते हैं, और यह एक डेटा-मॉडल फ़ैसला है जो आप Base44 entity एडिटर में लेते हैं, स्थानीयकरण-टूल का फ़ैसला नहीं। इसे जल्दी प्लान करें, क्योंकि पहले से मौजूद रिकॉर्ड्स वाली entity पर बाद में भाषा फ़ील्ड जोड़ना नई entity में इसे शुरू से जोड़ने से कहीं ज़्यादा काम है।

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

Lovalingo अगस्त 2026 के अंत में बंद हो गया, और इसके प्रकाशित उपयोग-मामलों में Lovable, v0 और Bolt के साथ-साथ Base44 भी शामिल था। जिसने भी इसके ज़रिए Base44 ऐप को स्थानीयकृत किया था, उसे उन स्ट्रिंग्स के लिए कोई ठिकाना चाहिए। यह एक नया सेटअप नहीं बल्कि माइग्रेशन है: पहले एक्सपोर्ट करें, फिर कन्वर्ट करें। माइग्रेशन गाइड इसे विस्तार से समझाता है, और तुलना पेज यह बताता है कि जब ट्रांसलेशन किसी होस्टेड सर्विस से आपकी रिपॉज़िटरी में जाते हैं तो क्या बदलता है।

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

पुष्टि करें कि sync two-way है, न कि पुराना export। Base44 में GitHub पैनल खोलें और देखें कि यह किसी जुड़ी हुई रिपॉज़िटरी की रिपोर्ट करता है या नहीं; अगर यह "पुराना सेटअप ढूँढ रहे हैं?" वाला लिंक दिखाता है, तो आप one-way रास्ते पर हैं और आपको दोबारा कनेक्ट करने की ज़रूरत है।

पुष्टि करें कि आपकी डिफ़ॉल्ट ब्रांच main है। Base44 केवल उसी ब्रांच को वापस मिरर करता है, इसलिए कहीं और मर्ज हुआ pull request कभी एडिटर तक नहीं पहुँचता।

किसी रनटाइम लाइब्रेरी को ढूँढें। अगर आपने कभी Base44 से भाषाओं के लिए कहा था, तो हो सकता है इसने i18next या कोई हाथ से बनाया गया context जोड़ा हो; conversion वहाँ मौजूद चीज़ को बनाए रखता है और उसे फ़ीड करता है।

दूसरी भाषा में रिकॉर्ड जोड़ने से पहले तय करें कि entity कंटेंट को अपनी भाषा फ़ील्ड कहाँ से मिलेगी। यह हिस्सा कैटलॉग आपके लिए नहीं करेंगे।

अपना routing जाँचें। Base44 के पेज फ़ाइल-आधारित होते हैं, इसलिए URL में locale प्रीफ़िक्स एक routing फ़ैसला है जो आप एक बार लेते हैं, और यही तय करता है कि सर्च इंजन हर भाषा को कैसे देखते हैं। लैंग्वेज स्विचर और hreflang गाइड इन विकल्पों को कवर करता है और ये सीधे लागू होते हैं।

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

अगर Base44 में two-way GitHub sync पहले से चालू नहीं है तो उसे चालू करें, पुष्टि करें कि ब्रांच main है, और the app में रिपॉज़िटरी कनेक्ट करें। पहला pull request कोडबेस को कन्वर्ट करता है। इसके बाद बस एक मर्ज, एक Publish क्लिक, और आपकी माँगी हुई भाषाएँ रह जाती हैं। Lovable इंटीग्रेशन पेज उस बिल्डर के लिए यही फ़्लो बताता है जिसमें in-editor रास्ता है, और वहाँ लिखी अधिकतर बातें बिना बदलाव के Base44 पर लागू होती हैं।