आप Lovable app का स्थानीयकरण इस तरह करते हैं कि workflow का हर हिस्सा repository में रखा जाए: committed files के रूप में message catalogs, आपके locales के नाम वाली config file और build में उन्हें compile करने वाला CLI step। globalize.now AI-संचालित localization infrastructure है, जो यह पूरा loop आपके लिए चलाता है—आपके codebase से strings extract करता है, keys और locale files generate करता है और हर Git push पर translations sync करता है। इस पूरी chain में browser interface की जरूरत नहीं होती। जब आपका code लिखने वाला agent हो, तब यह बात जितनी सुनने में लगती है उससे कहीं अधिक महत्वपूर्ण है।
Dashboard AI-built workflow को क्यों बाधित करता है?
क्योंकि आपका agent dashboard खोल नहीं सकता। Lovable, Cursor, Claude Code और Copilot—सभी एक ही दो surfaces पर काम करते हैं: repository की files और terminal में commands। Dashboard इनमें से कोई भी नहीं है।
अब यह अंतर केवल पसंद का विषय नहीं, बल्कि documented assumption है। AGENTS.md—coding agents को यह बताने का convention कि project कैसे काम करता है—दिसंबर 2025 में Model Context Protocol के साथ Linux Foundation की Agentic AI Foundation को योगदान किया गया था। Linux Foundation की अपनी घोषणा के अनुसार, तब तक 20 से अधिक AI coding tools में 60,000 से अधिक open-source projects इस format को अपना चुके थे। इसका मूल विचार यही है कि project instructions ऐसी file में हों जिसे agent पढ़ सके।
Login के पीछे मौजूद translation state इस premise से बाहर रहती है। जब आपका agent Lovable app में नया button जोड़ता है, तो वह string भी जोड़ सकता है। लेकिन वह कहीं login करके translation grid को reconcile नहीं कर सकता। नतीजा: string English में ship होती है, mismatch बढ़ता जाता है और आपको इसका पता Germany के किसी user से चलता है।
एक दूसरी समस्या भी है, जो अधिक शांत तरीके से सामने आती है। जब corrections केवल vendor के interface में मौजूद हों, तो repository अब आपके app के text की सच्चाई का स्रोत नहीं रहती। दो sources of truth—जिनमें से एक को आपके tools inspect भी नहीं कर सकते—ऐसी debugging समस्या है जो deadline का इंतजार कर रही होती है।
Dashboard के बिना Lovable setup वास्तव में कैसा दिखता है?
आपके build में चार files और एक command। Lovable के generated apps React पर चलते हैं—या तो classic Vite stack पर या server rendering वाले TanStack Start पर—और दोनों का ढाँचा एक जैसा है।
1. Config में अपने locales के नाम दें। एक committed file ही वह सूची है जिसे बाकी सभी layers पढ़ती हैं।
// lingui.config.ts
import { defineConfig } from "@lingui/conf";
export default defineConfig({
sourceLocale: "en",
locales: ["en", "de", "es", "fr"],
catalogs: [
{
path: "src/locales/{locale}/messages",
include: ["src"],
},
],
});
2. Messages को catalogs में extract करें। lingui extract आपके source को scan करता है और हर locale के लिए एक .po catalog लिखता है। यह disk पर पहले से मौजूद content के साथ merge करता है, इसलिए re-run के बाद existing translations सुरक्षित रहती हैं—यही वह गुण है जो इसे automated loop में चलाने के लिए सुरक्षित बनाता है।
npx lingui extract
3. Build से पहले compile करें। lingui compile catalogs को runtime modules में बदलता है। --strict flag translation missing होने पर build fail कर देता है, जिससे production में होने वाला silent English fallback पहले ही दिखाई देने वाली red build में बदल जाता है।
{
"scripts": {
"build": "lingui compile --strict && vite build"
}
}
4. Push पर sync चलने दें। Locale जोड़ना locales array में edit होना चाहिए, support ticket नहीं। globalize.now repository को watch करता है, agent द्वारा जोड़ी गई strings extract करता है, हर locale के लिए keys और catalog entries generate करता है और उन्हें वापस commit कर देता है। Catalogs pull request में diff के रूप में आते हैं, इसलिए किसी भी अन्य change की तरह review किए जा सकते हैं।
हर stack के लिए पूरी walkthrough Lovable Vite guide और TanStack Start guide में उपलब्ध है।
Vendor के बंद होने पर dashboard-managed translations का क्या होता है?
वे vendor के साथ ही चली जाती हैं। इस महीने यह कोई काल्पनिक स्थिति नहीं है: Lovable और अन्य AI-builder apps के लिए बनी runtime translation service Lovalingo 31 अगस्त 2026 को 23:59 CEST पर बंद हो रही है। नए projects और subscriptions पहले ही रोक दिए गए हैं, और company का अपना closure page customers को service हटाने से पहले उसके साथ-साथ project-owned internationalization लागू करने और फिर locale routes, fallbacks, canonical URLs, hreflang तथा sitemap output verify करने को कहता है।
यह vendor स्वयं बिल्कुल सही तरीके से बता रहा है कि workflow को किराये पर लेने और उसका मालिक बनने में क्या अंतर है।
| Dashboard-managed | Repo-native catalogs | |
|---|---|---|
| Translations कहाँ रहती हैं | Vendor database | आपकी repository की files |
| इन्हें कौन edit कर सकता है | Login वाला कोई human | कोई भी human, कोई भी coding agent, कोई भी script |
| Version history | Vendor का audit log | आपका Git history |
| Agent क्या पढ़ सकता है | कुछ भी नहीं | सब कुछ |
| Vendor के बंद होने पर | Translations को बचाकर निकालना होगा | कुछ नहीं बदलता |
| Rendered | Page load होने के बाद | Server-side, source में |
आखिरी row का एक SEO प्रभाव है, जो vendor के सवाल से कहीं अधिक समय तक रहता है। Load होने के बाद inject की गई translations crawler द्वारा पढ़े जाने वाले HTML में भरोसेमंद तरीके से मौजूद नहीं होतीं। Build में compile किए गए catalogs मौजूद होते हैं।
कैसे जाँचें कि आपके Lovable app की कोई dashboard dependency नहीं है?
तीन checks—और हर एक failure को स्पष्ट रूप से दिखाता है।
Network check करें। DevTools खोलकर app load करें, scripts पर filter लगाएँ और translation vendor के domain को भेजी गई requests देखें। अगर आपका German page German दिखने से पहले किसी third-party script के load होने पर निर्भर है, तो वह page किसी और की uptime पर निर्भर है।
Repository check करें। Config में मौजूद हर locale के लिए disk पर एक catalog file होनी चाहिए और वह Git द्वारा tracked होनी चाहिए। git ls-files "src/locales/**" चलाएँ और गिनती करें। Empty या missing catalogs का मतलब है कि strings कहीं और मौजूद हैं।
Build check करें। CI में --strict के साथ compile करें। Missing translation को deploy रोक देना चाहिए। अगर locale अधूरा होने पर भी आपका build pass हो जाता है, तो यह gap non-English UI में English text के रूप में सामने आएगा—यही वह failure mode है जिसे users कहते हैं, “site broken है।”
किसी existing vendor को हटाने से पहले, बाद में नहीं, preview deploy पर ये तीनों checks चलाएँ। Lovalingo की अपनी pre-removal checklist भी यही कहती है: replacement को real locale routes पर test किए जाने तक पुरानी service installed रखें। Migration path की सीधी जानकारी हमारी Lovalingo comparison में है।
Dashboard न होने पर globalize.now कहाँ फिट होता है?
आपके i18n runtime और translation engine के बीच वाली layer में। Lingui, i18next और next-intl जैसी libraries runtime पर translations serve करती हैं। DeepL और GPT translation जैसे engines text तैयार करते हैं। globalize.now बीच की चीज—keys और locale files—generate और maintain करता है, और उन्हें code के साथ current रखता है।
यही वह layer है जिसे पहले किसी व्यक्ति को interface में click करके manage करना पड़ता था। इसलिए interface हटाना feature loss नहीं, workflow change है। Setup एक बार होता है: repository को globalize.now से connect करें और conversion pull request के रूप में आ जाएगा। आपके editor में यही setup एक command है:
npx skills add globalize-now/globalize-skills
Lovable के भीतर यही capability in-editor skill के रूप में install होती है, इसलिए आपका app बनाने वाला agent इसे सीधे invoke कर सकता है। Starter plan की कीमत €20 प्रति workspace प्रति माह है, जिसमें हर महीने €20 का translation credit (लगभग 200,000 शब्द) शामिल है; इससे अधिक उपयोग उसी per-character rate पर billed होता है। न per-seat शुल्क है, न per-language शुल्क, और signup पर €5 का credit मिलता है—card की जरूरत नहीं। एक ही workspace में languages और projects unlimited हैं; पाँचवीं seat के बजाय पाँचवाँ locale जोड़ते समय यही बात महत्वपूर्ण होती है।
आसपास के workflow के बारे में vibe coders और developers के लिए अधिक जानकारी, तथा Lovable-specific setup के लिए Lovable integration page देखें।
संक्षेप में
आपके Lovable app की translations ऐसी files होनी चाहिए जिनके मालिक आप हों, ऐसी repository में जिन्हें आपका agent पढ़ सके और जिन्हें आपका अपना build compile करे। globalize.now हर Git push पर इन files को current रखता है।
globalize.now आपके ऐप्लिकेशन की हार्डकोडेड कॉपी को अनुवाद-तैयार locale फ़ाइलों में बदल देता है और जैसे-जैसे आप नई रिलीज़ करते हैं, उन्हें अपडेट रखता है।
globalize.now को निःशुल्क आजमाएं