Lovable वर्कस्पेस में lovable-i18n स्किल कैसे जोड़ें?

आप इसे GitHub से जोड़ते हैं: Settings खोलें, फिर Skills, फिर Add, फिर Import from GitHub, और Lovable को globalize-now/lovable-i18n repository की ओर पॉइंट करें। Lovable इसे डाउनलोड करता है, वैलिडेट करता है, और वर्कस्पेस में पब्लिश कर देता है, जहाँ हर प्रोजेक्ट इसका इस्तेमाल कर सकता है। globalize.now AI-पावर्ड स्थानीयकरण इंफ्रास्ट्रक्चर है: यह keys और locale files तैयार करता है, और आपके ऐप की runtime library उन्हें सर्व करती है। स्किल वही तरीका है जिससे यह सब Lovable एडिटर छोड़े बिना होता है, और यही वजह है कि इस पूरे रास्ते में कोई डैशबोर्ड नहीं आता।

Lovable स्किल असल में क्या होती है?

एक स्किल एक छोटी, नामित प्लेबुक है जिसे आप एक बार वर्कस्पेस स्तर पर स्टोर करते हैं। इसके तीन हिस्से होते हैं: एक स्थायी लोअरकेस नाम, एक description जो Lovable को बताती है कि इसे कब लोड करना है, और markdown इंस्ट्रक्शन्स जिन्हें Lovable लागू होने पर फॉलो करता है।

इसकी सबसे अहम बात यह है कि स्किल्स ज़रूरत पड़ने पर ही लोड होती हैं। वर्कस्पेस नॉलेज इससे अलग होती है — वह हमेशा कॉन्टेक्स्ट में मौजूद रहती है, और यहीं कोडिंग स्टैंडर्ड्स और ब्रांड नियम रखे जाने चाहिए। एक स्किल बातचीत में सिर्फ़ तब आती है जब रिक्वेस्ट उसकी description से मेल खाती है, इसलिए एक वर्कस्पेस बिना किसी अनावश्यक बोझ के कई फोकस्ड स्किल्स रख सकता है।

आप चैट इनपुट में / टाइप करके और उसे चुनकर किसी स्किल को जानबूझकर इनवोक कर सकते हैं, या फिर जब आपका प्रॉम्प्ट मेल खाए तो Lovable को इसे अपने-आप लागू करने दें। स्किल को कैसे की तरह और अपने प्रॉम्प्ट को क्या की तरह सोचें।

ये पोर्टेबल भी होती हैं। Lovable वही SKILL.md ढाँचा इस्तेमाल करता है जो Anthropic के Agent Skills convention में इस्तेमाल होता है, इसीलिए एक टूल के लिए लिखी गई स्किल बिना किसी बदलाव के दूसरे टूल में इम्पोर्ट हो जाती है। स्थानीयकरण के लिहाज़ से यह कोई छोटी बात नहीं है: इसका मतलब है कि Lovable के भीतर i18n तैयार करने वाले वही इंस्ट्रक्शन्स बाद में किसी ऐसे repository तक पहुँच सकते हैं जिसे आप Claude Code या Cursor में खोलें।

Lovable ऐप सिर्फ़ अंग्रेज़ी में ही क्यों आता है?

क्योंकि जेनरेट किए गए कोड में कोई locale layer ही नहीं होती जो कुछ और परोस सके। जब आप Lovable से एक pricing page बनाने के लिए prompt देते हैं, तो वह heading को सीधे component में उस भाषा के literal टेक्स्ट के रूप में लिख देता है जिसमें आपने prompt लिखा था। हर बटन, empty state, toast और validation message भी इसी तरह जाता है।

बाद में agent से "app का translate कर दो" कहने पर आधा-अधूरा नतीजा मिलता है: जिन screens को उसने देखा, वे बदल जाती हैं, और आगे जो feature आप बनाते हैं वह फिर से English में आता है। हमने इस दोहराव को why Lovable translations drift में विस्तार से दर्ज किया है, और यह mechanism अब भी वही है — agent सामने रखे prompt को हल करता है, उसके पीछे की architecture को नहीं।

इसका समाधान structural और एक-बार वाला है: strings को keys दें, translations को files में रखें, और runtime को उन files से पढ़ने दें। एक skill इस काम के लिए एक बेहतरीन साधन है, ठीक इसलिए कि यह एक तय playbook है, न कि वह prompt जिसे आपको हर बार सही ढंग से लिखना पड़े।

lovable-i18n स्किल क्या इंस्टॉल करता है?

Lingui v6, जिसमें src/locales/[locale]/messages.po पर PO catalogs, extraction के लिए Trans macros, एक language switcher component, और एक GitHub Action शामिल है। यह पता लगाता है कि आपके project में कौन-सा stack इस्तेमाल हो रहा है और उसी के अनुसार scaffold करता है — Vite SPA या TanStack Start, जो दोनों Lovable जेनरेट करता है।

यह stack detection सुनने में जितना मामूली लगता है, उससे कहीं ज़्यादा अहम है। Lovable का डिफ़ॉल्ट जेनरेट किया गया stack server rendering के साथ TanStack Start में बदल गया है, और client-rendered SPA और server-rendered app के लिए सही i18n wiring अलग-अलग होती है। हमने server-rendered केस को अलग से the TanStack Start guide में कवर किया है; यह skill सही रास्ता खुद चुन लेती है, ताकि आपको यह जानने की ज़रूरत ही न पड़े कि आपको कौन-सा मिला है।

जो यह install नहीं करता, वह है हम पर एक runtime dependency। Catalogs आपके repository में मौजूद files हैं। अगर आप कल globalize.now को हटा दें, तो committed PO files वाला Lingui app हर उस भाषा को दिखाना जारी रखेगा जो उसके पास पहले से है।

आप skill को import कैसे करते हैं?

चार steps, हर workspace के लिए एक बार।

1. Lovable project को GitHub से connect करें। Chat input में + menu का उपयोग करें, GitHub चुनें, फिर Connect project पर क्लिक करें। Catalogs को रहने के लिए एक असली repository चाहिए।
2. Skill को import करें। Settings, फिर Skills, फिर Add, फिर Import from GitHub, https://github.com/globalize-now/lovable-i18n की ओर pointed। SKILL.md repository के root में है, जो वही layout है जिसकी Lovable को तब ज़रूरत होती है जब आप उसे पूरी repository का URL देते हैं। एक बड़े skills repository के अंदर की subdirectory भी काम करती है, tree या blob URL का उपयोग करके।
3. globalize MCP जोड़ें। Connectors खोलें, Custom MCP चुनें, और https://api.globalize.now/mcp जोड़ें। जब sign-in step आती है, तो skill आपको उसमें कदम-दर-कदम गाइड करती है।
4. Lovable को prompt दें। उससे कहें कि वह lovable-i18n skill और globalize MCP का उपयोग करके i18n सेट करे और app को translate करे।

शुरू करने से पहले दो बातें जानना ज़रूरी है। Custom workspace skills बनाना, edit करना, delete करना और import करना केवल workspace owners और admins तक सीमित है — editors हर skill को देख और invoke तो कर सकते हैं, लेकिन नई skill नहीं जोड़ सकते। और Settings से skill जोड़ने पर credits खर्च नहीं होते; बाद में जो message उसका उपयोग करता है, वह किसी भी अन्य build message की तरह ही priced होता है।

सही URLs के साथ पूरी step-by-step जानकारी the Lovable integration page पर मौजूद है।

यह कौन-सा MCP है, और कौन-सा नहीं?

यही वह हिस्सा है जो सबसे ज़्यादा भ्रम पैदा करता है, और इसे उल्टा समझ लेने पर आपकी पूरी दोपहर बर्बाद हो सकती है।

Lovable दो MCP surfaces देता है, जो विपरीत दिशाओं में काम करते हैं। mcp.lovable.dev पर मौजूद Lovable MCP server, किसी बाहरी agent — ChatGPT, Claude, Cursor, VS Code — को कहीं और से आपके Lovable projects बनाने और edit करने देता है। Chat connectors, जिन्हें Connectors के अंतर्गत एक custom MCP के रूप में जोड़ा जाता है, इसका उलटा हैं: वे Lovable agent को यह क्षमता देते हैं कि जब आप app बना रहे हों, तब वह किसी बाहरी tool तक पहुँच सके।

globalize MCP दूसरी तरह का है। आप Lovable agent को यह क्षमता दे रहे हैं कि वह आपका localization project बनाए, catalogs को translate करे और repository को connect करे — और इसके लिए आपको इसके लिए कोई दूसरा product खोलने की ज़रूरत नहीं। Lovable के अपने documentation में भी यह फ़र्क साफ़ तौर पर बताया गया है, जो यह संकेत देता है कि यह लोगों को अक्सर उलझाता है।

इसका व्यावहारिक नतीजा यह है: अगर आप खुद को यह काम करवाने के लिए Claude या Cursor में कोई URL paste करते पाएं, तो आप गलत surface पर हैं। यहाँ बताया गया सब कुछ Lovable editor के भीतर ही होता है।

पहली setup के बाद क्या होता है?

Skill scaffold करती है, और diff GitHub से sync हो जाता है। इसे किसी भी अन्य बदलाव की तरह review करें — Lingui config, PO catalogs, वे component edits जो strings को Trans macros में लपेटते हैं, language switcher — और फिर अपनी default branch में merge करें।

इसके बाद, conversion का काम पूरा हो जाता है। यह एक-बार होने वाला और app के भीतर ही होने वाला काम है: आपने repository को connect किया, और globalize.now ने codebase को एक बार convert करके catalog तैयार किया। इसके बाद, push jobs नए catalog units को translate करती हैं और उन्हें एक pull request के रूप में डिलीवर करती हैं, जिसे आप merge करते हैं। आप Lovable को सामान्य रूप से prompt करते रहते हैं; नई strings untranslated literals के रूप में इकट्ठा होने के बजाय catalog में जाकर बैठ जाती हैं।

इसमें कोई export step नहीं है, कोई import step नहीं है, और कोई ऐसा screen नहीं है जहाँ कोई एक-एक करके strings को approve करता है। अगर आप यह जानना चाहते हैं कि यह क्यों अहम है, तो इसकी पूरी दलील localizing a Lovable app without a dashboard में है।

Translation widget के बजाय skill क्यों?

क्योंकि widget और catalog दो अलग-अलग तरह के आउटपुट बनाते हैं, और उनमें से सिर्फ़ एक ही असल में आपका होता है।

एक runtime widget — Weglot model — page लोड होने के बाद browser में टेक्स्ट को फिर से लिखने के लिए JavaScript inject करता है। इसमें आपको पहले English का एक झलका दिखता है, strings की लंबाई बदलने के साथ layout भी बदलता है, और index में एक ही English page होता है, जबकि translation client-side होता है जहाँ crawler को उसे भरोसे से देख पाना मुश्किल होता है। यह किसी भी site पर काम करता है, जो इसकी असली खूबी है, और उस marketing page के लिए एक ठीक-ठाक विकल्प है जिसका code आपके नियंत्रण में नहीं है।

एक committed catalog इसके विपरीत trade-off है। इसके लिए code access चाहिए, जो आपके पास है, और इसके बदले translated markup आपकी अपनी repository से render होता है, हर भाषा के लिए एक अलग indexable page के साथ। Lovalingo ने खासतौर से Lovable के लिए runtime model पर काम किया था और 31 अगस्त 2026 को बंद हो गया; अगर आप उससे migrate कर रहे हैं, तो migration guide में बताया गया है कि जो आपके पास था उसे export कैसे करें। यह बंद होना file-based approach के लिए सबसे स्पष्ट दलील भी है: आपके Git history में मौजूद PO catalogs किसी कंपनी के अस्तित्व में बने रहने पर निर्भर नहीं करते।

अगर आप mechanism की बजाय नतीजे पर केंद्रित पूरी end-to-end जानकारी चाहते हैं, तो making a Lovable app multilingual से शुरू करें। अगर आप शुरू करने से पहले लागत जानना चाहते हैं, तो pricing page पर मौजूदा plans देखें।

इसे एक बार जोड़ें

Import एक बार होने वाली workspace action है, और यह मुफ़्त है। इसके बाद, i18n वह चीज़ है जिसे आप chat input में किसी भी अन्य feature की तरह माँग सकते हैं, और translations आपके पास files के रूप में आते हैं, जिनके मालिक आप खुद होते हैं।