अगर आपका Lovable ऐप आपके द्वारा जोड़ी गई किसी भी language के बावजूद English में render होता है, तो वजह stack में बदलाव है: मई 2026 के मध्य से नए Lovable projects पुराने React और Vite single-page app के बजाय TanStack Start और server-side rendering पर ship होते हैं। globalize.now इस नए stack के अनुरूप आपके strings को committed Lingui PO catalogs में extract करता है, ताकि सही language server पर render हो, ब्राउज़र में बाद में swap न करनी पड़े। समाधान कोई दूसरा widget नहीं है। Translation को अपनी repo में ले जाना है, जहाँ server उसे render कर सके और search engines उसे index कर सकें।

आपके Lovable ऐप का localization अचानक कठिन क्यों हो गया?

क्योंकि पुराने advice के नीचे की ज़मीन बदल गई है। ज़्यादातर “अपने Lovable ऐप का अनुवाद करें” guides client-rendered single-page app मानकर चलती हैं, जहाँ widget load होने के बाद DOM rewrite कर सकता है और किसी को पता नहीं चलता। नए projects के लिए यह assumption अब गलत है।

Lovable ने नए projects को TanStack Start और SSR पर इसलिए स्थानांतरित किया कि crawlers को पहले request पर पूरी तरह rendered HTML मिले, बिना JavaScript चलाए। यह SEO के लिए वास्तविक लाभ है, लेकिन इससे translation का तरीका उलट जाता है। जब पहला response पहले से rendered हो, तो उसे बाद में ब्राउज़र में translate करना बहुत देर हो जाती है।

अगर आपने पिछले कुछ महीनों में अपना ऐप बनाया और उसमें runtime translation widget जोड़ दिया, तो आपको यही symptom दिख रहा होगा: पहले English की झलक, फिर swap। Lovable integration for globalize.now ठीक इसी समस्या को सही layer पर संभालने के लिए मौजूद है।

Lovable के TanStack Start switch में वास्तव में क्या बदला?

Rendering model client-side से server-side हो गया। पहले Lovable React और Vite से बने single-page apps generate करता था, जो static files के रूप में deploy होते और पूरी तरह ब्राउज़र में render होते थे। अब आधार TanStack Start है—एक full-stack React framework, जिसमें per-route SSR, SSG और CSR के साथ components के पास colocated server functions भी हैं।

Localization के लिए तीन बातें महत्वपूर्ण हैं। पहली, HTML ब्राउज़र तक पहुँचने से पहले server पर बनता है, इसलिए language का निर्णय server-side होता है। दूसरी, routing अब वास्तविक per-locale URLs को support करती है। तीसरी, browser-only APIs पर निर्भर होकर language चुनने वाली कोई भी चीज़ server के एक language पर commit करने के बाद चलती है।

अधिकांश broken setups इसी तीसरे बिंदु पर अटके होते हैं। localStorage में saved locale server को दिखाई नहीं देता, इसलिए server default language render करता है और client एक क्षण बाद उसे ठीक करता है।

SSR पर runtime translation widgets English की झलक क्यों दिखाते हैं?

क्योंकि server English भेज चुका होता है और उसके बाद widget अनुवाद करता है। नए stack पर क्रम यह है: server default language में HTML render करता है, ब्राउज़र उसे paint करता है, फिर widget की JavaScript load होकर text rewrite करती है। Paint और rewrite के बीच का अंतर ही English की वह झलक है, और अब यह tuning की समस्या नहीं बल्कि architecture का हिस्सा है।

SEO की लागत उस झलक से भी बड़ी है। Crawler पहला response पढ़कर आगे बढ़ जाता है। अगर translated text केवल client-side JavaScript चलने के बाद दिखाई देता है, तो crawler हर locale के लिए English index करता है और आपके पास rank करने के लिए per-language pages नहीं होते। Lovable के SSR पर जाने का पूरा उद्देश्य—indexable HTML—ब्राउज़र में translation करने से निष्प्रभावी हो जाता है।

कमिट किए गए कैटलॉग इस समस्या को डिज़ाइन के स्तर पर ही रोकते हैं। जब अनुवाद स्ट्रिंग्स आपके repo में रहती हैं, तो TanStack Start सर्वर पर अनुरोधित locale रेंडर करता है, इसलिए पहला response ही सही होता है। यही आपके codebase में मौजूद infrastructure और उसके ऊपर चलने वाले widget के बीच टिकाऊ अंतर है। इसी वजह से Weglot जैसे runtime tools नए मॉडल की तुलना में पुराने SPA मॉडल के लिए बेहतर अनुकूल हैं। sync समस्या पर विस्तृत चर्चा के लिए देखें: why Lovable translations break on every push।

TanStack Start पर बनी Lovable app को multilingual कैसे बनाएं?

अनुवाद को सर्वर पर ले जाएँ और कैटलॉग अपने repo में रखें। नए stack पर व्यावहारिक रूप से इसके चार चरण हैं, और इनमें से किसी के लिए भी आपको locale files हाथ से संपादित नहीं करनी पड़ेंगी।

  1. lovable-i18n skill जोड़ें और Lovable से i18n सेट अप करवाएँ। अपने Lovable workspace में lovable-i18n skill जोड़ें, फिर Lovable को internationalization सेट अप करने के लिए prompt दें। यह Lingui इंस्टॉल करता है, hardcoded UI strings को message catalogs में निकालता है और provider कॉन्फ़िगर करता है। Editor के बाहर यही सेटअप npx skills add globalize-now/globalize-skills से इंस्टॉल होता है (सभी agents के लिए इंस्टॉल करने हेतु --all जोड़ें)।
  2. TanStack के optional path param से locales को route करें। TanStack Router optional path parameters के लिए {-$locale} का उपयोग करता है। इसलिए /{-$locale}/about के रूप में परिभाषित route आपकी default language के लिए /about और Spanish के लिए /es/about—दोनों से match होता है। इससे हर भाषा के लिए अलग, crawlable URL मिलता है, बजाय ऐसे एक URL के जिसका text browser में बदलता रहे।
  3. Locale को localStorage में नहीं, सर्वर पर resolve करें। सक्रिय भाषा को cookie में रखें, ताकि SSR handler उसे request से पढ़ सके। Lingui के साथ server router बनाने से पहले setupLocaleFromRequest() कॉल करता है, और client hydration render करने से पहले server से मिले locale के साथ dynamicActivate() कॉल करता है। दोनों तरफ एक ही value होने से hydration mismatch और flash—दोनों नहीं होते।
  4. कैटलॉग अपने repo में रखें और हर push पर sync करें। PO catalogs committed files हैं, किसी vendor का runtime नहीं। Lovable में काम करते रहने पर नई strings आती रहेंगी, जिन्हें फिर extract और translate करना होगा—और यही वह हिस्सा है जो हाथ से करने पर धीरे-धीरे बिगड़ता है। globalize.now यही काम अपने-आप करता है, इसलिए बिना manual export step के कैटलॉग हमेशा अपडेट रहते हैं।
// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

क्योंकि यह committed output वाली वास्तविक step-by-step प्रक्रिया है, इसलिए यह standard version-controlled code की तरह काम करती है: pull request में review की जा सकती है, diff देखे जा सकते हैं और Lovable छोड़ने पर भी इसे आसानी से साथ ले जाया जा सकता है।

TanStack Start i18n stack में globalize.now की भूमिका कहाँ है?

यह runtime library के नीचे और translation engine के ऊपर एक layer के रूप में काम करता है। TanStack Start और Lingui runtime पर translations serve करते हैं, जबकि DeepL या कोई LLM स्वयं translations तैयार करता है। globalize.now इनके बीच का infrastructure है: यह keys और PO catalogs बनाता है और उन्हें sync रखता है, ताकि runtime के पास render करने के लिए हमेशा सही सामग्री हो।

Lovable builder के लिए इसका व्यावहारिक अर्थ है कि आपको locale files की लगातार देखभाल नहीं करनी पड़ती। Skill इंस्टॉल करें, Lovable को एक बार prompt दें, और उसके बाद हर push नई strings extract करता है, कैटलॉग भरता है और बदलाव को सामान्य PR के रूप में खोलता है। न dashboard का चक्कर, न दोबारा export, न app के text और catalogs के बीच कोई drift।

Pricing एक ही plan पर आधारित है: प्रति workspace €20/माह, जिसमें हर महीने €20 का translation credit (लगभग 200,000 शब्द) शामिल है; इसके बाद उसी प्रति-character दर पर token-based usage लागू होता है। न per-seat शुल्क है, न per-language शुल्क। Signup पर €5 credit मिलता है और card की आवश्यकता नहीं होती। पाँच locales वाली सामान्य Lovable app इसके भीतर आसानी से आ जाती है। Developer-side विवरण के लिए globalize.now for developers और vibe coders पेज देखें; बाकी stack का परिचय product overview में है।

आपकी Lovable app English में इसलिए अटकी है क्योंकि translation गलत जगह—browser में—हो रही है, जबकि server पहले ही एक भाषा चुन चुका होता है। Translation को अपने repo में ले जाएँ, तो server पहली request पर ही सही भाषा render करेगा। globalize.now extraction और sync संभालता है, इसलिए आप इसे एक बार सेट अप करते हैं और हर push पर यह अपडेट रहता है।

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

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