Lovable i18n नियम कहाँ से पढ़ता है? Knowledge, skills और AGENTS.md

Lovable i18n नियम तीन जगहों से पढ़ता है: वर्कस्पेस और प्रोजेक्ट knowledge, जो हमेशा संदर्भ में रहते हैं; skills, जो तभी लोड होते हैं जब कोई प्रॉम्प्ट उनके विवरण से मेल खाए; और कनेक्टेड रिपॉजिटरी की निर्देश फ़ाइलें, जहाँ रूट पर मौजूद AGENTS.md बातचीत कितनी भी लंबी हो, हर बार पढ़ी जाती है। नियम गलत जगह रख दिए जाएँ तो पिछले हफ़्ते अनुवादित ऐप अपना अगला फ़ीचर अंग्रेज़ी में ही भेज देता है। globalize.now एआई-संचालित स्थानीयकरण इन्फ्रास्ट्रक्चर है, इसलिए हम इस गलती का नतीजा कई Lovable रिपॉजिटरी में देखते हैं; समाधान काफ़ी हद तक यह जानना है कि कौन-सी सतह कब पढ़ी जाती है।

अनुवादित Lovable ऐप वापस अंग्रेज़ी पर क्यों लौट आता है?

क्योंकि जिस निर्देश ने उसे बहुभाषी बनाया था, वह अगला कंपोनेंट लिखते समय एजेंट के सामने मौजूद ही नहीं था। Lovable वही प्रॉम्प्ट हल करता है जो स्क्रीन पर है। अगर प्रॉम्प्ट कहता है "testimonials सेक्शन जोड़ो" और संदर्भ में कहीं नहीं लिखा कि "उपयोगकर्ता को दिखने वाली हर स्ट्रिंग <Trans> से होकर जाए", तो शीर्षक literal बनकर आ जाता है, ठीक वैसे ही जैसे बिल्कुल नए प्रोजेक्ट में आता।

यह वही समस्या नहीं है जिसमें catalogs कोड से पीछे रह जाते हैं; वह सिंक की विफलता है, जिसकी चर्चा हर शिप के साथ आपके Lovable ऐप के अनुवाद क्यों टूट जाते हैं में की गई है। सिंक केवल wrap की हुई स्ट्रिंग को locale files में ले जाता है। जिस स्ट्रिंग को कभी wrap ही नहीं किया गया, उसे वह नहीं ले जा सकता। असली सवाल यह है कि कोड लिखते समय Lovable क्या पढ़ रहा था, और इस बारे में Lovable के दस्तावेज़ असामान्य रूप से स्पष्ट हैं।

बदलाव करने से पहले Lovable असल में क्या पढ़ता है?

उसके knowledge दस्तावेज़ों के अनुसार, प्रोजेक्ट कोड के साथ-साथ प्रोजेक्ट knowledge, वर्कस्पेस knowledge और Git रिपॉजिटरी की निर्देश फ़ाइलें, जैसे AGENTS.md या CLAUDE.md, सभी एजेंट का मार्गदर्शन करती हैं। Skills अलग हैं और ज़रूरत पड़ने पर लोड होते हैं।

i18n के लिहाज़ से इनमें तीन अंतर मायने रखते हैं।

ये कब पढ़े जाते हैं। Knowledge हर संदेश में शामिल होता है। Skill तभी शामिल होता है जब अनुरोध उसके विवरण से मेल खाए। रूट की AGENTS.md, Lovable के शब्दों में, सत्र कितना भी लंबा हो, हमेशा पढ़ी जाती है।

लंबी चैट में ये कितने टिकाऊ हैं। Lovable के दस्तावेज़ों में स्पष्ट चेतावनी है कि बहुत लंबी बातचीत में, जहाँ संदर्भ बहुत ज़्यादा हो, knowledge के निर्देशों का हमेशा एक-सा पालन नहीं हो सकता। उसी पेज पर रूट की AGENTS.md के लिए इसके उलट दावा किया गया है। यही विषमता इस पोस्ट की पूरी वजह है।

इन्हें कौन संपादित कर सकता है। वर्कस्पेस knowledge केवल owner और admin ही बदल सकते हैं। प्रोजेक्ट knowledge को वह हर व्यक्ति बदल सकता है जिसके पास प्रोजेक्ट पर edit अधिकार हैं। रिपॉजिटरी की फ़ाइल को वह हर व्यक्ति बदल सकता है जो push कर सकता है, जिसमें स्वयं Lovable एजेंट भी शामिल है।

हर knowledge स्तर में अधिकतम 10,000 अक्षर आ सकते हैं। एक पॉइंटर के लिए यह काफ़ी है, लेकिन जब आप आर्किटेक्चर नोट्स, डेटाबेस स्कीमा और ब्रांड वॉइस भी वहीं रखना चाहें तो पूरे नियम-समूह के लिए यह बहुत कम है।

तो फिर i18n नियम कहाँ रखे जाएँ?

रिपॉजिटरी में, और knowledge में एक छोटा पॉइंटर। इसका तर्क ऊपर की तुलना से निकलता है।

रिपॉजिटरी के रूट पर AGENTS.md में पूरे नियम रहते हैं। यह सत्र की लंबाई की परवाह किए बिना हर संदेश पर पढ़ी जाती है, Git में रहती है इसलिए नई चैट, नए सहयोगी और किसी दूसरे एजेंट पर जाने के बाद भी बची रहती है, और इस पर कोई अक्षर-सीमा नहीं है जो आपके बाकी प्रोजेक्ट संदर्भ से होड़ करे। जब lovable-i18n skill अपना सेटअप चलाता है, तो उसका तीसरा चरण ठीक यही फ़ाइल लिखता है: <!-- lovable-i18n:rules:start --> और <!-- lovable-i18n:rules:end --> मार्करों के बीच Lingui नियमों का एक ब्लॉक, जो फ़ाइल न हो तो बना दिया जाता है, हो तो उसमें जोड़ दिया जाता है, और दोबारा चलाने पर मार्करों के बीच बदल दिया जाता है ताकि कुछ दोहराया न जाए।

प्रोजेक्ट knowledge में दो पंक्तियों का पॉइंटर रहता है। कुछ इस तरह:

Localization
- This app is localized with Lingui. Every user-visible string is wrapped
  (<Trans>, t``, msg``) and new strings are appended to src/locales/*/messages.po.
- The full rules are in AGENTS.md at the repo root. Follow them on every edit.

यह पॉइंटर उसी स्थिति के लिए है जिसकी दस्तावेज़ों में चेतावनी दी गई है। अगर लंबी बातचीत में knowledge ब्लॉक का असर घट गया हो, तब भी एजेंट के पास रिपॉजिटरी की फ़ाइल रहती है; और अगर किसी कारण से रिपॉजिटरी की फ़ाइल संदर्भ में न हो, तो पॉइंटर ज़रूरी शर्त का नाम बता देता है। दो जगहें, एक नियम।

वर्कस्पेस knowledge केवल तब, जब हर प्रोजेक्ट एक ही लाइब्रेरी इस्तेमाल करता हो। वर्कस्पेस knowledge सभी प्रोजेक्ट पर लागू होता है और उसकी एक ही प्रति होती है। अगर आपके आधे प्रोजेक्ट Lingui पर हैं और आधे किसी और पर, तो वर्कस्पेस स्तर का Lingui नियम आधे प्रोजेक्ट के लिए गलत है, और टकराव होने पर Lovable को वैसे भी प्रोजेक्ट knowledge को प्राथमिकता देने का निर्देश दिया गया है। वर्कस्पेस knowledge में वही नियम रखें जो हर जगह सही हों: बटन में sentence case, कोई console.log नहीं, कोड की टिप्पणियाँ अंग्रेज़ी में।

नियमों का घर skill नहीं है। जिन्होंने इसे अभी-अभी इम्पोर्ट किया है, उन्हें यह बात चौंकाती है। Skill तब लोड होता है जब प्रॉम्प्ट उसके विवरण से मेल खाए, इसलिए lovable-i18n तब संदर्भ में होता है जब आप i18n सेटअप माँगते हैं और तब नहीं होता जब आप चेकआउट पेज माँगते हैं। यह जानबूझकर ऐसा है; जो skill हर संदेश पर लोड हो, वह तो बस knowledge ही होता। Skill का काम है टिकाऊ नियमों को एक बार रिपॉजिटरी में लिख देना और फिर रास्ते से हट जाना।

AGENTS.md के नियम क्या कहते हैं?

वे उन सवालों के जवाब देते हैं जिन पर एजेंट तब गलती करता है जब उससे बस "i18n इस्तेमाल करो" कह दिया जाता है। Skill जो ब्लॉक लिखता है उसके छह हिस्से हैं।

कौन-सा macro। एक निर्णय-सूची: जो टेक्स्ट किसी संख्या के साथ बदलता है, वह <Plural> या ICU plural इस्तेमाल करता है; JSX टेक्स्ट <Trans> इस्तेमाल करता है; attribute मान और इवेंट-हैंडलर की स्ट्रिंग, जैसे toasts, useLingui() से मिले t का इस्तेमाल करती हैं; मॉड्यूल-स्कोप के constants msg इस्तेमाल करते हैं और कंपोनेंट के भीतर resolve किए जाते हैं। नियम यह भी बताता है कि हर एक किस import पाथ से आता है, क्योंकि गलत t import एक ऐसा ग्लोबल इंस्टेंस बाँध देता है जिसे ऐप कभी लोड ही नहीं करता।

इंटरपोलेशन। केवल सादा वेरिएबल ही एक्सट्रैक्ट किए गए संदेश में अपने स्लॉट का नाम स्वयं बताता है। कोई भी दूसरा एक्सप्रेशन {0} के रूप में एक्सट्रैक्ट होता है, जिसके साथ अनुवादक काम नहीं कर सकता, इसलिए नियम माँगता है कि उसे नाम देने के लिए ph() इस्तेमाल किया जाए।

Plurals। other हमेशा अनिवार्य है, श्रेणियाँ CLDR की हैं, और दो स्ट्रिंग के बीच ternary वर्जित है क्योंकि वह अंग्रेज़ी के plural नियम को कंपोनेंट में स्थायी रूप से बाँध देता है। पृष्ठभूमि के लिए, ICU MessageFormat क्या है उस सिंटैक्स को समझाता है जिसमें plural रूप कम्पाइल होते हैं।

संख्या और तारीख़। i18n.number() और i18n.date(), कभी toFixed() नहीं, और न ही किसी मान से जोड़ा गया करेंसी चिह्न। Lovable के अपने वर्कस्पेस-knowledge उदाहरण में एक localization सेक्शन है जो तारीख़ का फ़ॉर्मैट और यूरोपीय संख्या-फ़ॉर्मैट तय करता है, जो अच्छी सूझ है, लेकिन वह फ़ॉर्मैटिंग का नियम है, wrap करने का नहीं। कोई ऐप इसका पूरा पालन करके भी हर शीर्षक अंग्रेज़ी में भेज सकता है।

अनुवादक टिप्पणियाँ। कई अर्थों वाली छोटी स्ट्रिंग, केवल क्रिया दर्शाने वाले लेबल और डोमेन शब्दों के साथ एक comment= जाता है, जो बताता है कि वह स्ट्रिंग कहाँ दिखती है। context= केवल तब इस्तेमाल होता है जब एक ही टेक्स्ट को अलग-अलग जगह अलग अनुवाद चाहिए।

Catalog की देखभाल। हर नई स्ट्रिंग wrap की जाती है और हर src/locales/*/messages.po में खाली msgstr के साथ जोड़ दी जाती है, ताकि अनुवाद आने तक Lingui मूल टेक्स्ट पर लौट आए। एजेंट कभी lingui extract नहीं चलाता, क्योंकि Lovable में टर्मिनल नहीं है; सिंक के बाद वह काम GitHub Action करता है। और वह मौजूदा एंट्री की #. और #: टिप्पणी पंक्तियों को कभी संपादित नहीं करता, क्योंकि एक्सट्रैक्शन उन्हें दोबारा बना देता है।

यही आख़िरी सेक्शन इन नियमों को Lovable-विशिष्ट बनाता है। Cursor या Claude Code की नियम फ़ाइल "linter चलाओ" पर ख़त्म हो सकती है। Lovable की नियम फ़ाइल ऐसा नहीं कर सकती, इसलिए उसे बताना पड़ता है कि इसके बजाय हाथ से क्या करना है और CI के लिए क्या छोड़ना है।

जब Lovable कुछ चला ही नहीं सकता, तब नियम कौन लागू करवाता है?

GitHub workflow, और केवल GitHub workflow। Lovable में टर्मिनल नहीं है, इसलिए एजेंट के literal लिखने और बदलाव के आपकी रिपॉजिटरी में सिंक होने के बीच कोई lint चरण नहीं होता। IDE एजेंटों से यही संरचनात्मक अंतर है, जहाँ हार्डकोड की गई स्ट्रिंग पर CI में lint नियम ही बिल्ड को फ़ेल करता है।

अगर आप सेटअप के दौरान इसे चुनते हैं, तो skill एक GitHub Actions workflow जोड़ता है जो डिफ़ॉल्ट ब्रांच पर हुए push पर चलता है (Lovable का सिंक वहीं पहुँचता है), wrap की गई स्ट्रिंग को catalogs में एक्सट्रैक्ट करता है, और catalog sync को वापस commit कर देता है। अगर GitHub ऐप के पास workflows अनुमति नहीं है, तो skill आपसे GitHub में वह फ़ाइल हाथ से जोड़ने को कहता है। जो कुछ एजेंट ने wrap किया है, उसके लिए यह चक्र पूरा कर देता है। जिस स्ट्रिंग को एजेंट ने wrap नहीं किया, उसके लिए यह कुछ नहीं करता, क्योंकि एक्सट्रैक्शन केवल macros देखता है।

तो सच्ची तस्वीर यह है: AGENTS.md के नियम बिना wrap किए literal के आने की आवृत्ति घटाते हैं, knowledge का पॉइंटर लंबी चैट में उन्हें सहारा देता है, और बाकी को पकड़ने की जगह GitHub का diff है। अगर आप चाहते हैं कि बाकी को कोई मशीन पकड़े, तो उसी workflow में एक चरण के रूप में eslint-plugin-i18next का no-literal-string नियम जोड़ दें। यह रिपॉजिटरी पर चलता है, जो Lovable प्रोजेक्ट में कुछ भी चलाने की एकमात्र जगह है।

जो स्ट्रिंग wrap हो जाती हैं, उनका क्या होता है?

उनका अनुवाद होना चाहिए, और यही वह हिस्सा है जिसे बार-बार प्रॉम्प्ट देने के बजाय स्वचालित करना सार्थक है। रूपांतरण एक बार का काम है और ऐप के भीतर होता है: रिपॉजिटरी कनेक्ट करें, और globalize.now कोडबेस को एक बार कन्वर्ट करके catalog को pull request के रूप में देता है, जिसकी आप समीक्षा करते हैं। इसके बाद push jobs नई catalog इकाइयों का अनुवाद उनके आते ही कर देते हैं, इसलिए मंगलवार को Lovable का लिखा <Trans> बुधवार तक अपने अनुवादों के साथ pull request में होता है। कोई डैशबोर्ड चरण नहीं, कोई एक्सपोर्ट नहीं, कोई अनुमोदन कतार नहीं; इस ढाँचे का विस्तृत तर्क डैशबोर्ड के बिना Lovable ऐप का स्थानीयकरण में है, और GitHub कनेक्शन तथा globalize कनेक्टर सहित सेटअप का सटीक रास्ता Lovable इंटीग्रेशन पेज पर है।

एक ऐतिहासिक टिप्पणी, क्योंकि इससे समझ आता है कि कुछ Lovable बिल्डरों को यह समस्या नई क्यों लगती है। Lovalingo Lovable ऐप का अनुवाद ब्राउज़र में रनटाइम पर करता था, इसलिए नया बना अंग्रेज़ी कंपोनेंट लोड होते ही दोबारा अनुवादित हो जाता था और यह समस्या कभी सामने नहीं आई। यह 31 अगस्त 2026 को बंद हो गया, और जो ऐप माइग्रेशन गाइड से commit किए गए catalogs पर आए, वे इस बुनियादी सवाल से पहली बार रूबरू हो रहे हैं। Catalog मॉडल सही सौदा है, क्योंकि अनुवादित मार्कअप आपका अपना है और इंडेक्स किया जा सकता है, लेकिन इसमें एजेंट से अनुवाद-योग्य कोड लिखवाना पड़ता है, और इसका मतलब है उसे बताना कि नियम कहाँ हैं।

नियम वहाँ रखें जहाँ Lovable उन्हें पढ़ता है

Skill को एक बार चलाएँ ताकि AGENTS.md में पूरा ब्लॉक आ जाए, दो पंक्तियों का पॉइंटर प्रोजेक्ट knowledge में चिपका दें, और वह एक्सट्रैक्शन GitHub workflow को करने दें जो एडिटर नहीं कर सकता। अगर आप Lovable में बना रहे हैं और चाहते हैं कि catalog तक पहुँचने वाली हर चीज़ का अनुवाद संभाला जाए, न कि आपको उसे संभालना पड़े, तो vibe coders पेज इसका परिचय है और प्राइसिंग का अपना अलग पेज है।