Classic Vite stack पर बनी Lovable app को localize करने का सबसे अच्छा तरीका है hardcoded strings को committed Lingui PO catalogs में extract करना, न कि runtime translation widget जोड़ना। आपकी Lovable app client-rendered React SPA है, इसलिए इसमें server render उपलब्ध नहीं है जिससे translation जोड़ी जा सके। टिकाऊ विकल्प यही है कि translation files आपके अपने repo में रहें और build के साथ deploy हों। globalize.now AI-संचालित localization infrastructure है, जो extraction करता है और हर Git push पर catalogs को sync रखता है—इसलिए एक बार सेट अप करने के बाद आपको locale files को फिर हाथ से manage नहीं करना पड़ता।

आपकी Lovable app classic Vite पर है या TanStack Start पर?

पहले अपना file tree देखें, क्योंकि Lovable दो अलग stacks देता है और दोनों के लिए i18n setup अलग होता है। यदि आपको src/pages/Index.tsx, src/main.tsx और vite.config.ts दिखाई देते हैं, तो आप classic Vite plus React SPA stack पर हैं, जो Lovable का default है। TanStack Start projects में इसके बजाय src/routes/, src/router.tsx, src/routeTree.gen.ts और src/server.ts होते हैं।

Project बनाते समय stack चुना जाता है और बाद में बदला नहीं जा सकता, इसलिए यह निर्णय आपके लिए पहले ही हो चुका है। Classic Vite stack पूरी तरह browser में render होता है और default रूप से server-side data fetching नहीं करता। यह guide classic Vite SPA को कवर करती है। यदि आपकी files TanStack Start layout से मेल खाती हैं, तो इसके बजाय हमारी TanStack Start i18n guide for Lovable देखें, क्योंकि server rendering से translations load होने का तरीका बदल जाता है।

Vite SPA वाली Lovable apps को i18n tooling क्यों नज़रअंदाज़ कर देती है?

क्योंकि tooling का ध्यान Lovable के नए TanStack Start plus SSR default पर चला गया और classic Vite SPA को पर्याप्त समर्थन नहीं मिला, जबकि यह अब भी Lovable का सबसे आम stack है। पिछले कुछ महीनों में Lovable को target करने वाले localization tools—जिनमें Lovalingo, Intlayer और Paraglide शामिल हैं—ने अपने guides को server-side rendering वाले TanStack Start पर केंद्रित कर दिया है।

इससे एक स्पष्ट gap रह गया है। Client-rendered SPA की वास्तविक सीमाओं को SSR guides नज़रअंदाज़ करती हैं: translated markup inject करने के लिए कोई server render नहीं होता, पूरा bundle browser में load होता है और देर से load होने वाली कोई script English UI के ऊपर render हो सकती है। अच्छी बात यह है कि classic stack के लिए एक साफ़ और अच्छी तरह समर्थित समाधान मौजूद है, जिसके बारे में अधिकांश builders को पता ही नहीं चलता, क्योंकि सबसे चर्चित tools दूसरे stack के पीछे लगे हैं।

Committed catalogs और runtime translation widget में क्या अंतर है?

Committed catalogs वे translation files हैं जिन्हें आपके repository में check in किया जाता है और build time पर bundle किया जाता है। इसके विपरीत, runtime widget एक third-party script है, जो आपकी English UI load हो जाने के बाद browser में text बदलता है। Vite SPA के लिए यह अंतर तीन महत्वपूर्ण बातों को तय करता है।

पहला, flash और layout shift: widget पहले English दिखाता है, फिर उसे rewrite करता है, इसलिए users को स्पष्ट बदलाव दिखाई देता है और layout उछल सकता है। Committed catalogs पहली paint पर ही सही भाषा render करते हैं। दूसरा, indexability: आपके build के साथ ship होने वाली strings आपके source का हिस्सा होती हैं, जबकि widget का text देर से inject होता है और crawlers के लिए पढ़ना कठिन होता है। तीसरा, ownership: committed catalogs आपके repo की files हैं, इसलिए आपकी app को German या Japanese में बोलते रहने के लिए किसी बाहरी service के online रहने की आवश्यकता नहीं होती।

Lingui के साथ Lovable Vite app में i18n कैसे जोड़ें?

Lingui को अपनी i18n layer के रूप में जोड़ें, strings को wrap करें और उसके Vite plugin को catalogs compile करने दें। Lingui एक lightweight i18n framework है, जिसमें dedicated Vite plugin और PO-based catalog format है—ठीक वही जिसकी client-rendered SPA को आवश्यकता होती है।

पहले packages इंस्टॉल करें। Lingui अपने CLI, Vite plugin और React runtime को अलग-अलग रखता है:

npm install --save-dev @lingui/cli @lingui/vite-plugin @rolldown/plugin-babel
npm install @lingui/core @lingui/react

इसके बाद vite.config.ts में plugin register करें और एक lingui.config.ts जोड़ें, जो आपके source और locales folder की ओर संकेत करे:

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { lingui } from "@lingui/vite-plugin";

export default defineConfig({
  plugins: [react(), lingui()],
});

// lingui.config.ts
import { defineConfig } from "@lingui/cli";

export default defineConfig({
  locales: ["en", "de", "fr"],
  sourceLocale: "en",
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

फिर hardcoded JSX text को bare strings की तरह छोड़ने के बजाय Trans macro से wrap करें:

// before
<h1>Create your account</h1>

// after
import { Trans } from "@lingui/react/macro";
<h1><Trans>Create your account</Trans></h1>

अब extraction करें। CLI आपकी src directory को scan करता है और हर locale के लिए PO catalog लिखता है, जैसे src/locales/en/messages.po:

npx lingui extract

हर भाषा के लिए msgstr fields भरें, या यह चरण किसी automated layer को सौंप दें (अगला section देखें)। अलग compile command चलाने की आवश्यकता नहीं है, क्योंकि @lingui/vite-plugin development और build के दौरान PO catalogs को on the fly compile करता है।

अंत में runtime पर locale सक्रिय करके language switcher जोड़ें:

import { i18n } from "@lingui/core";
i18n.activate("de");

Classic Vite stack के लिए पूरा loop यही है: install, wrap, extract, translate, switch। Translations को छोड़कर बाकी सब कुछ आपके repo में रहता है।

globalize.now हर push पर इसे automate कैसे करता है?

globalize.now आपके repo पर नज़र रखकर हर Git push पर manual extract-and-fill steps अपने-आप पूरा करता है। यह आपके Lovable codebase में नई hardcoded strings ढूँढता है, Lingui की अपेक्षा के अनुसार keys और PO entries बनाता है, translations तैयार करता है और updated catalogs को वापस commit कर देता है। इसलिए आपके src/locales folder को current रखने के लिए आपको commands चलाने की आवश्यकता नहीं होती।

globalize.now पर repository को एक बार connect करें और यह निगरानी शुरू कर देगा। यदि आप इसे अपने editor से सेट अप करना चाहते हैं, तो skills इंस्टॉल करें:

npx skills add globalize-now/globalize-skills

विशेष रूप से Lovable के अंदर अपने workspace में lovable-i18n skill जोड़ें, फिर Lovable को i18n सेट अप करने के लिए prompt दें। Runtime Lingui ही रहता है, इसलिए आपकी app के render होने के तरीके में कोई बदलाव नहीं आता। बदलाव सिर्फ इतना है कि आपको locale files की लगातार देखभाल नहीं करनी पड़ती। यही एक बार सेट अप करें, हर push पर sync करें वाला मॉडल हमारे vibe-coder workflow और developer setup की नींव है।

Solo builder के लिए pricing सीधी है: प्रति workspace €20/माह, बिना per-seat और per-language शुल्क के, साथ ही केवल आपके वास्तविक translation usage का भुगतान। नए workspaces को बिना card के €5 signup credit मिलता है, जो एक छोटी app को end-to-end translate करने के लिए पर्याप्त है।

क्या इसके बजाय runtime widget इस्तेमाल करना चाहिए? Lovalingo से मिलने वाला सबक

यदि आप चाहते हैं कि आपके translations किसी एक vendor से अधिक समय तक टिकें, तो नहीं। Runtime translation widget शुरुआत में सुविधाजनक होता है, लेकिन इससे आपकी app किसी और के server के online रहने पर निर्भर हो जाती है—और यह dependency वास्तविक failure mode बन सकती है।

Lovable builders के बीच लोकप्रिय runtime widget Lovalingo ने घोषणा की है कि वह 31 अगस्त 2026 को बंद हो जाएगा। नए signups स्वीकार नहीं किए जा रहे हैं और किसी successor का नाम नहीं बताया गया है। उसकी अपनी migration guidance users को project-owned internationalization पर जाने की सलाह देती है—यानी ठीक वही committed-catalog approach जिसे यह guide समझाती है। Widget vendor बंद होने पर injected translations रुक जाती हैं और UI English पर लौट आती है। आपके repo में मौजूद files ऐसा नहीं होने देतीं। यदि आप पहले से widget इस्तेमाल कर रहे हैं, तो हमारी Lovalingo shutdown migration guide इस बदलाव की पूरी प्रक्रिया बताती है। व्यापक translations-break-on-every-push problem ही वह कारण है जिसकी वजह से AI-built apps के लिए committed catalogs बेहतर हैं।

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

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