Lovalingo 31 अगस्त 2026 को बंद हो रहा है। चूँकि यह आपके ऐप का अनुवाद अपनी runtime service के ज़रिए करता है, इसलिए अगर आप पहले migrate नहीं करते तो आपकी multilingual site भी इसके साथ बंद हो जाएगी। समाधान वही है जिसकी सिफारिश Lovalingo की अपनी closure guidance करती है: project-owned internationalization। globalize.now AI-संचालित स्थानीयकरण infrastructure है जो Lovable apps के लिए ठीक यही करता है। यह आपके UI strings को आपके repository में commit किए गए Lingui PO catalogs में extract करता है और हर Git push पर translation PR sync करता है, ताकि आपकी भाषाएँ इस shutdown समेत किसी भी vendor के बंद होने के बाद भी बनी रहें। और चूँकि यह migration आपकी पसंद से नहीं हो रही, Lovalingo migrators को पहले तीन महीनों का usage मुफ़्त मिलता है। नीचे देखें: क्या टूटेगा, क्या सुरक्षित रखना है, migration कैसे करनी है और वे removal steps जिन्हें अधिकांश guides छोड़ देती हैं।

Lovalingo ने क्या घोषणा की?

Lovalingo ने घोषणा की कि वह 31 अगस्त 2026 को 23:59 CEST पर बंद हो जाएगा और नए projects व subscriptions स्वीकार करना पहले ही रोक चुका है। यह घोषणा lovalingo.com पर site-wide banner और एक dedicated service-closure page के रूप में उपलब्ध है। सेवा Tempo AI LLC द्वारा संचालित है।

Terms व्यवस्थित हैं। सक्रिय subscriptions के लिए billing collection रोक दी गई है, cutoff तक access जारी रहेगा और project configuration, routes, translation bundles व overrides वाले preservation exports तैयार किए जा रहे हैं। Migration support [email protected] तक उपलब्ध है।

बाकी बातों से अधिक दो विवरण महत्वपूर्ण हैं। पहला, किसी successor का नाम नहीं दिया गया है, इसलिए users को किसी दूसरे vendor के पास नहीं भेजा जा रहा। दूसरा, official migration guidance कहती है कि Lovalingo हटाने से पहले उसके साथ-साथ project-owned internationalization लागू करें। यह एक स्पष्ट architectural instruction है और एक runtime translation widget को दूसरे से बदलने के विकल्प को खारिज करता है।

Lovalingo बंद होने पर आपके ऐप का क्या होगा?

आपका ऐप अपनी source language पर लौट जाएगा। Lovalingo runtime layer की तरह काम करता है: आप @lovalingo/lovalingo install करते हैं, अपने ऐप को उसके provider में wrap करते हैं और translations उसकी infrastructure के ज़रिए serve होती हैं। आपके repository में कोई locale files मौजूद नहीं होतीं। सेवा response देना बंद कर दे तो आपका build compile और deploy होता रहेगा, लेकिन हर page untranslated render होगा।

एक और गंभीर failure mode है। Lovalingo का recommended sitemap setup एक prebuild script जोड़ता है, जो Lovalingo के CDN से आपका sitemap download करती है और download विफल होने पर build fail करने के लिए बनाई गई है। CDN offline होने के बाद उस script वाले projects पूरी तरह build होना बंद कर देंगे। अपने package.json में prebuild entry देखें, जो cdn.lovalingo.com से fetch करती हो। अगर वह मौजूद है, तो removal वैकल्पिक cleanup नहीं है—यही आपको shipping जारी रखने देता है।

SEO damage इसकी धीमी कीमत है। Lovalingo आपके locale URLs और hreflang tags runtime पर generate करता था; shutdown के बाद वे translated pages मौजूद नहीं रहेंगे और search engines उन pages को deindex कर देंगे जिन्हें वे crawl नहीं कर सकते। हमने जून में Lovalingo, Weglot और globalize.now की अपनी तुलना में structural argument दिया था: किसी भी runtime translation service के साथ आपकी multilingual site तभी तक मौजूद रहती है जब तक vendor मौजूद रहता है। तब यह एक hypothetical बात थी। अब इसकी तारीख तय है।

31 अगस्त 2026 से पहले आपको क्या करना चाहिए?

अभी अपना डेटा सुरक्षित करें और replacement तैयार करते समय Lovalingo चालू रखें। अगस्त के आख़िरी दिनों तक इंतज़ार न करें: अंतिम सप्ताह में [email protected] की support queue सबसे व्यस्त होगी और आपको production check विफल होने की स्थिति के लिए पर्याप्त समय चाहिए। एक समझदार लक्ष्य है कि migration 24 अगस्त तक पूरी हो जाए—यानी पूरे एक सप्ताह का buffer।

Lovalingo का closure page स्वयं sequence बताता है और यही सही क्रम है:

  1. अपने project export और वर्तमान source repository को सुरक्षित रखें। अगर export अभी तक नहीं आया है, तो आज ही [email protected] से उसका अनुरोध करें।
  2. अपनी वर्तमान language list और locale URL structure नोट कर लें। ये आपकी LovalingoProvider configuration और export में मौजूद हैं। आपको दोनों की हूबहू संरचना रखनी होगी।
  3. Lovalingo के साथ-साथ project-owned internationalization लागू करें। अभी कुछ भी न हटाएँ।
  4. Replacement पर direct locale URLs, page refreshes, missing keys और fallback behavior test करें।
  5. Replacement के production checks पास करने के बाद ही Lovalingo हटाएँ (पूरी removal checklist नीचे है)।

ध्यान दें कि step 3 क्या कहता है। Project-owned का अर्थ है कि translations आपके नियंत्रण वाली files के रूप में repository में रहें, किसी दूसरे vendor के runtime में नहीं। Lovalingo से दूसरे runtime widget पर जाना आपको इस migration को फिर से करने से केवल एक shutdown दूर रखता है। Lovalingo compare page दोनों architectures की साथ-साथ तुलना करती है।

Lovalingo से globalize.now पर कैसे migrate करें?

एक सामान्य Lovable ऐप के लिए migration rebuild नहीं, बल्कि एक working session का काम है और आपको Lovable editor छोड़ने की ज़रूरत नहीं पड़ती:

  1. Skill जोड़ें। अपने Lovable workspace में lovable-i18n जोड़ें या terminal से: npx skills add globalize-now/globalize-skills। Lovable integration page में पूरा flow दिया गया है।
  2. Lovable को i18n सेट अप करने के लिए prompt करें। इतना सरल prompt भी काम करता है: “इस ऐप के लिए lovable-i18n skill का उपयोग करके i18n सेट अप करें।” Skill Lovable को Lingui wire करने, hardcoded strings extract करने और PO catalogs बनाने का मार्गदर्शन देती है—ये plain files आपके repo में commit होती हैं।
  3. अपना Lovalingo setup match करें। वही target languages और वही locale path structure (/de/..., /fr/...) configure करें जो Lovalingo पर चल रहा था, ताकि पहले से indexed URLs live रहें। अगर कोई path बदलना ज़रूरी हो, तो 301 redirect जोड़ें।
  4. Push करें। globalize.now catalogs को उठा लेता है और आपकी target languages के लिए translation PR खोलता है। उसे merge करें और आपकी भाषाएँ वापस आ जाएँगी—इस बार आपके repo में files के रूप में।
  5. Lovalingo इंस्टॉल रहने पर ही परीक्षण करें। उनकी अपनी चेकलिस्ट चलाएँ: सीधे locale URL, रीफ़्रेश, missing keys, fallbacks और हर locale का metadata। नए Lovable प्रोजेक्ट SSR के साथ TanStack Start पर चलते हैं, इसलिए आपके locale routes server-rendered HTML के रूप में आते हैं; पुराने client-rendered React प्रोजेक्ट भी काम करते हैं, क्योंकि catalogs rendering mode से स्वतंत्र रूप से आपके repo में रहते हैं।

इंस्टॉल करने से पहले पूरा तरीका एक बार देखकर समझना चाहते हैं? Skill जोड़ने से लेकर translation PR merge होने तक का पूरा flow तीन मिनट का है:

How to Make Your Lovable App Multilingual (i18n in Minutes)

इसके बाद प्रक्रिया सरल है: एक बार सेटअप करें, हर Git push पर auto-sync हो, और किसी manual intervention की ज़रूरत न पड़े। कीमत €20 प्रति workspace प्रति माह है, जिसमें unlimited projects और languages, हर महीने €20 का translation credit (लगभग 200,000 शब्द) शामिल है। साइन-अप पर €5 का credit भी मिलता है और कार्ड की आवश्यकता नहीं है।

Lovalingo से migrate करने वालों के लिए इसके ऊपर एक विशेष ऑफ़र भी है: पहले तीन महीने का उपयोग पूरी तरह मुफ़्त। Migration आपका चुना हुआ नहीं था, इसलिए शुरुआती अवधि में आपसे कोई शुल्क नहीं लिया जाना चाहिए। इसे पाने के लिए साइन अप करें और [email protected] पर अपने Lovalingo project का उल्लेख करते हुए ईमेल भेजें; हम इसे आपके workspace में लागू कर देंगे।

Lovalingo को साफ़-सुथरे तरीके से कैसे हटाएँ?

हटाना केवल package uninstall करने जितना आसान नहीं है, क्योंकि Lovalingo आपके router और build में जुड़ जाता है। Replacement के परीक्षण में सफल होने के बाद यह checklist एक बार पूरी करें; हर item केवल तभी लागू होता है जब वह आपके setup में मौजूद हो:

  1. अपना router restore करें। Path mode में Lovalingo का LangRouter, BrowserRouter की जगह ले लेता है। इसे हटाते समय अपना original router वापस रखें, वरना ऐप render नहीं होगा।
  2. Internal links ठीक करें। यदि आपके code में LangLink या useLangNavigate जैसे Lovalingo helpers हैं, तो उन्हें अपने router के Link और navigation से बदलें। Package हटते ही ये imports काम करना बंद कर देंगे।
  3. Provider और package हटाएँ। अपने app shell से LovalingoProvider (और LangRouter) हटाएँ, फिर @lovalingo/lovalingo uninstall करें।
  4. Manifest हटाएँ। अपनी public directory से /.well-known/lovalingo.json हटाएँ या उसे generate करने वाले endpoint को हटा दें।
  5. Sitemap prebuild step हटाएँ। यदि package.json में scripts/fetch-lovalingo-sitemap.mjs और prebuild entry मौजूद हैं, तो दोनों हटा दें। Lovalingo का CDN बंद होने पर आपका build इसी script के कारण fail होगा। इसके बजाय अपना sitemap serve करें; committed locale routes होने पर यह आपके codebase से generate हो जाएगा।
  6. Redeploy करें और फिर से submit करें। Cleaned build deploy करें, पुष्टि करें कि locale URLs translated content render कर रहे हैं, और Google Search Console में अपना sitemap फिर से submit करें, ताकि rebuilt pages दोबारा crawl हो सकें।

दस मिनट की सफ़ाई के बाद, बंद हो रही service पर आख़िरी runtime dependency भी समाप्त हो जाती है।

क्या आप अपनी मौजूदा Lovalingo translations बचाए रख सकते हैं?

Export संभालकर रखें। यह reference के रूप में उपयोगी है, लेकिन drop-in import के रूप में नहीं। globalize.now आपके source strings से translations बनाता है और परिणाम आपके repo में commit करता है, इसलिए एक push के भीतर आपकी languages वापस आ जाती हैं। जिन specific phrases या product terms के लिए आपने Lovalingo में manual overrides किए थे, उन्हें globalize.now glossary और manual edits में शामिल करें, ताकि आपके लिए महत्वपूर्ण wording migration के बाद भी बनी रहे।

ईमानदार trade-off यह है: आप किसी vendor के bundle format को port करने के बजाय translations दोबारा generate कर रहे हैं। बदले में, यह इसी तरह का आपका आख़िरी migration होगा। Output आपके repository में PO files के रूप में रहता है—परिभाषा के अनुसार portable।

अगर आपका ऐप Lovable से नहीं बना है तो क्या होगा?

वही migration काम करता है। Lovalingo React, Next.js, v0, Bolt और Claude Code projects को भी serve करता था, और globalize.now इन्हें उसी skills package के ज़रिए support करता है: इसे अपने agent के लिए install करें, strings को Lingui catalogs में extract होने दें, push करें और PR merge करें। developers और vibe coders के लिए flow Lovable path जैसा ही है, बस Lovable editor शामिल नहीं है। ऊपर दी गई removal checklist ज्यों की त्यों लागू होती है, और तीन महीने मुफ़्त वाला migration offer भी।

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

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