Lovalingo बंद होने से पहले मैं अपने अनुवाद कैसे export करूँ?

अभी Lovalingo से अपना preservation export माँगें, फिर translation bundles को अपने repo में commit किए गए PO catalogs में बदलें। Lovalingo सक्रिय projects के लिए exports तैयार कर रहा है और सेवा 31 अगस्त 2026 को 23:59 CEST पर बंद होने तक [email protected] के ज़रिए support उपलब्ध है। globalize.now AI-संचालित स्थानीयकरण infrastructure है: यह आपके बचाए गए strings से repo में locale files बनाता है और हर Git push पर उन्हें sync रखता है, इसलिए यह आख़िरी translation export होगा जिसे आपको कभी करना पड़ेगा।

31 अगस्त को Lovalingo बंद होने पर मेरे अनुवादों का क्या होगा?

आपकी source language को छोड़कर हर भाषा में rendering बंद हो जाएगी, क्योंकि translated text आपके ऐप में था ही नहीं। Lovalingo एक runtime layer है: आपका Lovable ऐप English में ship होता है और उसकी सेवा हर विज़िटर के लिए text बदलती है। सेवा बंद होते ही यह बदलाव भी बंद हो जाएगा।

Closure terms Lovalingo के service-closure page पर सार्वजनिक हैं। नए projects और subscriptions पहले ही बंद हैं। सक्रिय projects 31 अगस्त 2026 को 23:59 CEST तक काम करते रहेंगे। Billing collection रोक दी गई है और सक्रिय projects के लिए preservation exports तैयार किए जा रहे हैं।

यह deadline वास्तव में data deadline है। Cutoff के बाद export करने के लिए कोई सेवा नहीं होगी और पूछने के लिए कोई support inbox भी नहीं। अगर आज आपके ऐप को French या German में traffic मिल रहा है, तो उन अनुवादों को बनाने में लगा पूरा काम गायब हो जाएगा—जब तक आप उसे पहले बाहर न निकाल लें।

मैं अपना translation data Lovalingo से बाहर कैसे निकालूँ?

अपना preservation export माँगें और उसे अपने source repository के साथ सुरक्षित रखें। Closure page के अनुसार, exports में project की उपलब्ध configuration, routes, translation bundles, overrides और integrity evidence शामिल हैं—यानी आपकी भाषाओं के बारे में runtime को ज्ञात हर चीज़।

1. Export माँगें। सक्रिय projects के लिए exports तैयार किए जा रहे हैं। अगर आपका export अभी तक नहीं मिला है, तो [email protected] पर email करके अपने project के लिए export delivery का अनुरोध करें।
2. दोनों चीज़ें साथ सुरक्षित रखें: export file और आपके वर्तमान source repository का snapshot। Export अनुवादों का विवरण देता है; repo वह ऐप है जिससे वे जुड़े हैं।
3. Lovalingo अभी uninstall न करें। उनकी अपनी guidance के अनुसार, replacement के production checks पास करने तक इसे installed रखें। बदलाव के दौरान दोनों systems साथ-साथ चल सकते हैं।

Translation bundles सबसे महत्वपूर्ण हिस्सा हैं। इनमें हर locale के वास्तविक translated strings के साथ dashboard में किए गए manual overrides भी होते हैं। Overrides अक्सर भूल जाते हैं: ये edits केवल Lovalingo में मौजूद हैं, किसी ऐसे machine-translation engine में नहीं जिन्हें आप दोबारा चला सकें।

Lovalingo bundles को अपने repo के स्वामित्व वाले catalogs में कैसे बदलूँ?

Bundles को gettext PO catalogs में बदलकर commit करें। PO plain text होता है, Git में इसके diffs साफ़ दिखते हैं और React apps के लिए Lingui इसी format को compile करता है। इसमें Lovable द्वारा जनरेट किए जाने वाले दोनों stacks शामिल हैं: classic Vite SPA और नया TanStack Start SSR default।

Runtime bundles आम तौर पर हर locale के लिए key-value maps होते हैं। Conversion के लिए project नहीं, एक छोटी script चाहिए:

// convert.mjs — JSON bundle → PO entries
import fs from "node:fs";

const locale = process.argv[2]; // e.g. "de"
const bundle = JSON.parse(fs.readFileSync(`bundles/${locale}.json`, "utf8"));

const po = Object.entries(bundle)
  .map(([source, translated]) =>
    `msgid ${JSON.stringify(source)}\nmsgstr ${JSON.stringify(translated)}\n`)
  .join("\n");

fs.writeFileSync(`src/locales/${locale}/messages.po`, po);

Exact field names export के अनुसार अलग हो सकते हैं, इसलिए कुछ चलाने से पहले अपना export जाँच लें। सिद्धांत वही रहता है: source string अंदर, msgid/msgstr pair बाहर, हर locale के लिए एक .po file, जिसे src/locales/ के अंतर्गत commit किया जाए।

अगर conversion खुद लिखना आपका काम नहीं है, तो Lovalingo migration guide managed path समझाती है। Closure window के दौरान Lovalingo से migrate करने वालों को तीन महीने का usage मुफ़्त भी मिलता है।

बचाए गए catalogs को अपने Lovable ऐप में कैसे wire करूँ?

अपने Lovable workspace में lovable-i18n skill जोड़ें, फिर Lovable को i18n सेट अप करने के लिए prompt करें; skill आपके stack में Lingui wire करती है और आपके द्वारा commit किए गए PO catalogs को उठा लेती है। Lovable editor के बाहर यही setup इस तरह install होता है:

npx skills add globalize-now/globalize-skills

आप किस stack पर हैं, इससे wiring details तय होती हैं। मई 2026 से पहले जनरेट किए गए apps अधिकतर classic Vite SPAs हैं; नए apps में default रूप से SSR वाला TanStack Start आता है। दोनों के लिए अलग walkthrough उपलब्ध है: Lovable Vite apps के लिए i18n और Lovable के TanStack Start stack पर i18n। Lovable integration page skill के end-to-end काम को समझाती है।

इसके बाद Lovalingo runtime में जिस maintenance समस्या को हल करता था, वह आपके repo में हल हो जाती है। आपके द्वारा ship की गई नई strings हर push पर extract, translate और translation PR के रूप में commit हो जाती हैं। Pricing €20/month प्रति workspace है, जिसमें हर महीने €20 का translation credit (लगभग 200,000 शब्द) शामिल है; इसके बाद उसी प्रति-character rate पर token-based usage लागू होता है। न per-seat charges हैं, न per-language charges—इसलिए छठा locale जोड़ने की लागत दूसरे locale जितनी ही रहती है। यह उन vibe coders के लिए बनाया गया है जो locale files के बारे में कभी सोचना नहीं चाहते।

Lovalingo हटाने से पहले मुझे क्या test करना चाहिए?

पहले replacement को production conditions में test करें; removal आख़िरी चरण है, पहला नहीं। Lovalingo का अपना pre-removal sequence एक अच्छी checklist है और यह committed-catalog setup पर सीधे लागू होता है:

• Direct locale URLs। हर भाषा एक वास्तविक route (/de/, /fr/) पर उपलब्ध होनी चाहिए, जो hard refresh पर load हो—सिर्फ client-side switching के ज़रिए नहीं।
• Missing keys और fallbacks। किसी translation को locally delete करके पुष्टि करें कि ऐप blank render करने के बजाय source string पर fallback करता है।
• हर locale के लिए SEO metadata। हर भाषा के titles, descriptions, canonical URLs, hreflang pairs और sitemap जाँचें। Server-rendered locale routes इन्हें JavaScript pass के बिना crawlers के लिए उपलब्ध कराते हैं; make your Lovable app multilingual guide में इसका पूरा तरीका बताया गया है।
• इसके बाद ही widget हटाएँ। Committed-catalog version के checks पास करने के बाद Lovalingo हटाएँ और checks फिर से चलाएँ।

इस बदलाव का एक शांत लाभ यह है कि vendor के plans बदलने से checklist की कोई चीज़ regress नहीं हो सकती। अब catalogs आपके Git history में files के रूप में मौजूद हैं।

आपका export एक बार किया गया rescue है। globalize.now इसे आख़िरी export बनाता है: इसे एक बार सेट अप करें और आपके catalogs हर Git push पर extract, translate और commit होते रहें।