Lovable में multilingual होने पर वास्तव में क्या होता है

आप Lovable को नया pricing section जोड़ने का प्रॉम्प्ट देते हैं। Lovable कंपोनेंट जनरेट करके उसे जोड़ता है और रिलीज़ कर देता है। आपका अंग्रेज़ी UI अपडेट हो जाता है। आपके messages.po कैटलॉग अब भी वही दिखाते हैं जो पहले मौजूद था। फ़्रेंच यूज़र्स को पुराना टेक्स्ट दिखता है। जर्मन यूज़र्स को अंग्रेज़ी दिखती है। किसी वास्तविक यूज़र की शिकायत आने तक किसी को पता नहीं चलता।

यह Lovable का बग नहीं है। यह एक संरचनात्मक असंगति है। Lovable UI को तेज़ी से रिलीज़ करने के लिए ऑप्टिमाइज़ है। i18n के लिए हर बदलाव पर, हर locale catalog में, यूज़र को दिखने वाली हर स्ट्रिंग को ट्रैक करना पड़ता है। ये दोनों लक्ष्य सीधे एक-दूसरे के विरोध में हैं।

एक्सट्रैक्शन की समस्या एक बार की नहीं, लगातार चलने वाली है। Lovable का हर प्रॉम्प्ट नई स्ट्रिंग्स बना सकता है। हर iteration मौजूदा कंटेंट बदल सकती है। ऐसा कोई स्वाभाविक checkpoint नहीं है जहाँ आप कह सकें, “एक्सट्रैक्शन पूरा हो गया।”

आम समाधान टिकाऊ क्यों नहीं हैं

क्या एक बार का extraction run समस्या ठीक कर देता है?

नहीं। शुरुआती Lovable build के बाद आप string extraction चला कर साफ़-सुथरे PO कैटलॉग बना सकते हैं। लेकिन यह अगले प्रॉम्प्ट तक ही काम करता है। उसके बाद आपको दर्जनों कंपोनेंट्स और दर्जनों कैटलॉग के diffs की मैन्युअल तुलना करनी पड़ती है। आपके Spanish messages.po कैटलॉग में एक स्ट्रिंग छूट जाए तो Spanish यूज़र्स को अनुवादित पेज के बीच अंग्रेज़ी टेक्स्ट दिखेगा—इसे mixed-language UI कहते हैं, और यह आपके प्रोडक्ट में आने वाले सबसे ज़्यादा भरोसा तोड़ने वाले अनुभवों में से एक है।

क्या रनटाइम ट्रांसलेशन टूल पर्याप्त अच्छे हैं?

Weglot जैसे रनटाइम ट्रांसलेटर या JavaScript से इंजेक्ट किए गए ट्रांसलेशन विजेट अलग समस्या हल करते हैं। वे पेज लोड होने के बाद कंटेंट का अनुवाद करते हैं, इसलिए अनुवादित कंटेंट आने से पहले यूज़र्स को कुछ क्षण मूल भाषा दिखाई देती है। खराब यूज़र अनुभव के अलावा, इससे मापने योग्य Cumulative Layout Shift पैदा होता है—यह Core Web Vitals का एक संकेतक है जिसका इस्तेमाल Google पेजों की रैंकिंग के लिए करता है। आप एक अदृश्य मेंटेनेंस समस्या को दिखाई देने वाली परफ़ॉर्मेंस समस्या से बदल रहे हैं।

Lovable को locale files अपडेट करने का प्रॉम्प्ट देने भर से काम क्यों नहीं चलेगा?

आप कहें तो Lovable PO कैटलॉग में लिख सकता है। समस्या यह है कि हर प्रॉम्प्ट पर, हर स्ट्रिंग के लिए, हर locale में ऐसा करने की बात आपको याद रखनी होगी। हर नई भाषा के साथ यह मानसिक बोझ बढ़ता जाता है। चार locales से गुणा करें तो हर UI प्रॉम्प्ट चार चरणों वाली coordination exercise बन जाता है। यही वह friction है जो Lovable को उपयोगी बनाने वाली गति को खत्म कर देता है।

Lovable का i18n चक्र वास्तव में कैसे टूटता है

पैटर्न इतना लगातार दोहराता है कि इसकी एक पहचानी जाने वाली रूपरेखा बन जाती है:

  1. शुरुआती सेटअप — आप multilingual support जोड़ते हैं। यह काम करता है। सब कुछ अनुवादित है। आप संतुष्ट होते हैं।
  2. शुरुआती कुछ रिलीज़ — आपको PO कैटलॉग मैन्युअली अपडेट करना याद रहता है। परेशानी होती है, लेकिन संभाली जा सकती है।
  3. गति का चरण — आप तेज़ी से रिलीज़ करने लगते हैं। PO कैटलॉग पीछे छूटने लगते हैं। आप खुद से कहते हैं कि बाद में पूरा कर लेंगे।
  4. प्रोडक्शन में mixed-language UI — गैर-अंग्रेज़ी बाज़ारों के यूज़र्स को आंशिक अंग्रेज़ी दिखने लगती है। सपोर्ट टिकट आने लगते हैं। आप एक पूरा रिलीज़ चक्र केवल स्ट्रिंग्स ढूँढने में लगा देते हैं।
  5. रिफ़ैक्टर टैक्स — अब हर नए फ़ीचर की एक छिपी हुई i18n लागत है, जो केवल-अंग्रेज़ी वर्ज़न में नहीं थी। आपकी रिलीज़ गति घट जाती है।

रिफ़ैक्टर टैक्स उस हिस्से का नाम है जिसके बारे में “Lovable में multilingual कैसे करें” वाली गाइड लिखते समय कोई बात नहीं करता। गाइड शुरुआती सेटअप दिखाती हैं, रिलीज़ 12 के बाद क्या होता है, यह नहीं।

समाधान: i18n को अपने Git push cycle में जोड़ें

सही आर्किटेक्चरल समाधान है मैन्युअल चरणों को पूरी तरह हटाना। अगर हर push पर translations अपने-आप अपडेट हों, तो मेंटेनेंस की समस्या खत्म हो जाती है। extraction अपने-आप चलता हो तो उसे चलाना भूल ही नहीं सकते।

वर्कफ़्लो इस तरह दिखता है:

  1. अपने Lovable प्रोजेक्ट को GitHub से कनेक्ट करें। चैट इनपुट में + मेन्यू खोलें, फिर GitHub चुनें और Connect project पर क्लिक करें।
  2. अपने वर्कस्पेस में lovable-i18n skill जोड़ें। Lovable वर्कस्पेस में Skills खोलें, फिर Add, फिर Import from GitHub चुनें और https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n पेस्ट करें। पुष्टि करें। यह हर वर्कस्पेस के लिए एक बार करना है (वर्कस्पेस ओनर या एडमिन की अनुमति आवश्यक)।
  3. Lovable से सेटअप करने को कहें। Lovable चैट में यह पेस्ट करें: Set up i18n for my project using the lovable-i18n skill.। Lovable आपका स्टैक (Vite SPA या TanStack Start) पहचानता है और एक सवाल पूछता है—source language, target languages, URL में locale रखना है या नहीं, और GitHub Action जोड़ना है या नहीं। डिफ़ॉल्ट के लिए go का जवाब दें। यह Lingui इंस्टॉल करता है, src/locales/{locale}/messages.po पर PO कैटलॉग तैयार करता है, स्ट्रिंग्स को <Trans> मैक्रोज़ में रैप करता है और language switcher जोड़ता है।
  4. रिव्यू और मर्ज करें। Lovable GitHub से सिंक करता है; diff की समीक्षा करके उसे अपनी default branch में मर्ज करें।
  5. रिपॉज़िटरी को globalize.now से कनेक्ट करें। साइन इन करें, रिपॉज़िटरी कनेक्ट करें, GitHub ऐप को अधिकृत करें, अपनी Lovable रिपॉज़िटरी और default branch चुनें, फिर भाषाएँ चुनें (50+ भाषाएँ, RTL सहित)।
  6. Lovable में बिल्ड करते रहें। हर push पर globalize.now अपडेटेड PO कैटलॉग के साथ translation PR खोलता है। उसे मर्ज करें और ऐप अनुवादित होकर रिलीज़ हो जाता है।

मुख्य बात यह है कि कनेक्ट और सिंक करने के चरण सेटअप के बाद आपसे कुछ नहीं माँगते। आपको कोई कमांड नहीं चलानी, कोई डैशबोर्ड नहीं देखना और translation queue को मंज़ूरी नहीं देनी। Lovable द्वारा जनरेट किए गए कंपोनेंट्स की नई स्ट्रिंग्स push पर पकड़ी जाती हैं, उनका अनुवाद होता है और branch मर्ज करने से पहले PR के रूप में वापस आ जाती हैं। चरण-दर-चरण सेटअप Lovable integration पेज पर है।

आपके Lovable वर्कफ़्लो के लिए इसका क्या अर्थ है

आपको Lovable का इस्तेमाल बंद करने की ज़रूरत नहीं है। यह आर्किटेक्चर इस धारणा पर बना है कि आपका UI लगातार बदलता रहेगा—आख़िर यही इसका उद्देश्य है। Lovable UI जनरेट करता है और lovable-i18n skill चलाता है; globalize.now सिंक संभालता है।

जब आपको i18n चाहिए, Lovable कंपोनेंट्स जनरेट करके skill लागू करता है। globalize.now हर push पर आउटपुट पर नज़र रखता है। आप कितनी भी तेज़ी से रिलीज़ करें, आपके यूज़र्स को हमेशा पूरा, अनुवादित UI दिखाई देता है।

globalize.now का vibe coders पेज खास तौर पर AI से बनाए गए ऐप्स के लिए सेटअप कैसे काम करता है, इसकी अधिक जानकारी देता है। अगर आप पहले से Lovable पर बना Next.js या React ऐप चला रहे हैं, तो developers पेज तकनीकी integration path बताता है।

जो टीमें पहले से कई Lovable प्रोजेक्ट मैनेज कर रही हैं, उनके लिए globalize.now की प्रति-वर्कस्पेस pricing का मतलब है कि आपको प्रति भाषा या प्रति string extraction भुगतान नहीं करना पड़ता—ऐप बढ़ने पर भी sync की लागत स्थिर रहती है।

मेंटेनेंस का बोझ वास्तविक है और समय के साथ बढ़ता जाता है। Lovable में lovable-i18n skill जोड़ें (अपने वर्कस्पेस में Skills खोलें, फिर Add, फिर Import from GitHub चुनें)। Lovable integration guide या globalize.now देखें।

globalize.now आपके ऐप्लिकेशन की हार्डकोडेड कॉपी को अनुवाद-तैयार locale फ़ाइलों में बदल देता है और जैसे-जैसे आप नई रिलीज़ करते हैं, उन्हें अपडेट रखता है।

globalize.now को निःशुल्क आजमाएं