क्या ट्रांसलेशन पुल रिक्वेस्ट Lovable के GitHub सिंक को तोड़ देती हैं?

नहीं, ट्रांसलेशन पुल रिक्वेस्ट Lovable के GitHub सिंक को नहीं तोड़ती, बशर्ते वह उसी एक ब्रांच में मर्ज हो जिसे Lovable सिंक कर रहा है। Lovable एक समय में एक ही ब्रांच पर एडिट करता है और मर्ज हुए कमिट को प्रोजेक्ट में वापस खींच लेता है, इसलिए ट्रांसलेशन पुल रिक्वेस्ट उस ब्रांच पर आने वाला एक और कमिट भर है। globalize.now AI-आधारित लोकलाइज़ेशन इन्फ्रास्ट्रक्चर है जो आपकी रिपॉजिटरी में ट्रांसलेशन को पुल रिक्वेस्ट के रूप में डिलीवर करता है, यानी दोनों सिस्टम सिर्फ़ एक सामान्य Git मर्ज पर मिलते हैं, कहीं और नहीं। जो मामले गड़बड़ होते हैं वे विशिष्ट और दस्तावेज़ों में दर्ज हैं, और यह पोस्ट उन्हीं को क्रम से समझाती है।

Lovable का GitHub सिंक असल में कैसे काम करता है?

यह दोनों दिशाओं में चलता है और सिर्फ़ एक ब्रांच पर काम करता है। Lovable के डॉक्यूमेंटेशन के अनुसार वह एक समय में एक ही ब्रांच को एडिट और सिंक करता है; बाय डिफ़ॉल्ट यह रिपॉजिटरी की डिफ़ॉल्ट ब्रांच होती है, आमतौर पर main। Lovable में आप जो बदलाव करते हैं वे उसी ब्रांच में कमिट होते हैं। GitHub पर उस ब्रांच में पुश किए गए कमिट वापस Lovable में खींच लिए जाते हैं।

Lovable के बाहर से आपके रेपो में लिखने वाली किसी भी चीज़ के लिए दो बातें मायने रखती हैं।

पुल एक नोटिफ़िकेशन पर निर्भर है। Lovable को GitHub से पुश नोटिफ़िकेशन मिलता है और वह प्रोजेक्ट अपडेट करता है। उसी डॉक्यूमेंटेशन के अनुसार, अगर वह नोटिफ़िकेशन कभी पहुँचे ही नहीं, तो उस पुश के कमिट Lovable में दिखाई नहीं देते। डॉक्यूमेंटेड समाधान है एक और कमिट पुश करना ताकि नया नोटिफ़िकेशन ट्रिगर हो। अगर आपने ट्रांसलेशन पुल रिक्वेस्ट मर्ज कर दी और एडिटर में अब भी अंग्रेज़ी दिख रही है, तो सबसे पहले यही जाँचें।

आप सिंक की जाने वाली ब्रांच बदल सकते हैं। प्रोजेक्ट की GitHub सेटिंग्स में एक ब्रांच पिकर होता है। वहाँ बनाई गई ब्रांच उस ब्रांच से फ़ोर्क होती है जो उस समय सक्रिय हो, अपने-आप main से नहीं। एक बार आप ब्रांच बदल दें, तो Lovable उसी ब्रांच को एडिट और सिंक करता है। इसके बाद main में मर्ज की गई कोई भी चीज़ एडिटर को तब तक नहीं दिखती जब तक वह Lovable वाली ब्रांच में मर्ज न हो जाए।

इस सेक्शन से अगर आपको सिर्फ़ एक वाक्य याद रखना हो, तो यह: ट्रांसलेशन पुल रिक्वेस्ट उसी ब्रांच पर लैंड होनी चाहिए जो पिकर में दिखती है।

जब GitHub Lovable का पुश रिजेक्ट कर दे तो क्या होता है?

Lovable बदलाव को खोने के बजाय lovable-sync नाम की ब्रांच पर सहेज देता है। Lovable के डॉक्स के अनुसार ऐसा तब होता है जब GitHub कॉन्फ्लिक्ट या ब्रांच प्रोटेक्शन नियमों की वजह से पुश रिजेक्ट कर देता है, और फिर आप lovable-sync को अपनी सामान्य रिव्यू प्रक्रिया से अपनी प्रोटेक्टेड ब्रांच में मर्ज करते हैं।

एक संबंधित सुरक्षा-जाल भी है: अगर Lovable जिस ब्रांच को सिंक कर रहा है वह GitHub पर डिलीट हो जाए, तो Lovable प्रोजेक्ट को lovable-fallback नाम की नई ब्रांच पर ले जाता है। और रिपॉजिटरी को ही डिलीट कर देने से कनेक्शन टूट जाता है और सिंक रुक जाता है, जबकि उसका नाम बदलने से ऐसा नहीं होता।

इनमें से कुछ भी सिर्फ़ ट्रांसलेशन तक सीमित नहीं है। Lovable के आसपास किसी दूसरे राइटर से यही व्यवहार अपेक्षित है, और ट्रांसलेशन पुल रिक्वेस्ट एक शिष्ट दूसरा राइटर है: वह रिव्यू योग्य पुल रिक्वेस्ट के रूप में आती है और प्रोटेक्टेड ब्रांच में सीधे कभी पुश नहीं करती।

ट्रांसलेशन पुल रिक्वेस्ट इस पूरे फ़्लो में कहाँ फ़िट होती है?

Lovable के कमिट और आपके मर्ज बटन के बीच। जिस Lovable प्रोजेक्ट में lovable-i18n skill पहले से इंस्टॉल है और Lovable की नॉलेज में इंस्ट्रक्शन नियम नई स्ट्रिंग्स को रैप करवाते रहते हैं, उसमें फ़्लो कुछ ऐसा दिखता है।

1. Lovable कोई फ़ीचर लिखता है और नई स्ट्रिंग्स को Lingui मैक्रो में रैप करता है। वह सिंक की जाने वाली ब्रांच में कमिट करता है।
2. एक GitHub वर्कफ़्लो रैप की गई स्ट्रिंग्स को src/locales/ के अंतर्गत PO कैटलॉग में एक्सट्रैक्ट करता है और सिंक को वापस कमिट कर देता है। Lovable में टर्मिनल नहीं है, इसलिए एक्सट्रैक्शन एडिटर में नहीं, GitHub में चलाना पड़ता है।
3. कन्वर्ज़न एक बार का काम है और ऐप के भीतर होता है: आप रिपॉजिटरी कनेक्ट करते हैं और globalize.now कोडबेस को एक बार कन्वर्ट करके कैटलॉग को पुल रिक्वेस्ट के रूप में डिलीवर करता है। इसके बाद पुश जॉब कैटलॉग की नई यूनिट्स का अनुवाद करते हैं और अनुवादित कैटलॉग भी पुल रिक्वेस्ट के रूप में डिलीवर करते हैं।
4. आप पुल रिक्वेस्ट को सिंक वाली ब्रांच में मर्ज करते हैं। Lovable मर्ज कमिट को खींच लेता है, और ऐप अब नई भाषा रेंडर करने लगती है।

ध्यान दें कि क्या-क्या नहीं है: Lovable में कोई इम्पोर्ट स्टेप नहीं, किसी वेब डैशबोर्ड से एक्सपोर्ट नहीं, और रनटाइम पर ट्रांसलेशन लोड करने वाला कोई विजेट नहीं। अनुवादित फ़ाइलें आपके रेपो में सादी फ़ाइलें हैं, और यही डैशबोर्ड के बिना Lovable ऐप का स्थानीयकरण का तर्क है; कनेक्शन के सटीक चरण Lovable इंटीग्रेशन पेज पर हैं।

क्या Lovable और ट्रांसलेशन पुल रिक्वेस्ट में कॉन्फ्लिक्ट हो सकता है?

हाँ, सामान्य Git के अर्थ में, और पुल रिक्वेस्ट को कम समय तक खुला रखने पर ऐसा कम ही होता है। कॉन्फ्लिक्ट के लिए ज़रूरी है कि ब्रांच बनने और मर्ज होने के बीच दोनों राइटर एक ही फ़ाइल की वही लाइनें बदलें।

व्यावहारिक रूप से ओवरलैप की एक ही जगह है: PO कैटलॉग। जब Lovable कोई स्ट्रिंग जोड़ता है, तो वह हर src/locales/*/messages.po में खाली ट्रांसलेशन के साथ एक नया मैसेज जोड़ देता है, इसलिए ऐप सोर्स टेक्स्ट पर फ़ॉलबैक करती है। ट्रांसलेशन पुल रिक्वेस्ट उन मैसेज का अनुवादित टेक्स्ट भरती है जो उसके खुलते समय कैटलॉग में पहले से मौजूद थे। अगर Lovable फ़ाइल के अंत में नए मैसेज जोड़ता है जबकि पुल रिक्वेस्ट उसी फ़ाइल में पहले की एंट्री बदल रही है, तो Git बिना शिकायत दोनों को मर्ज कर देता है। अगर दोनों एक ही एंट्री को छुएँ, तो आपको कॉन्फ्लिक्ट मार्कर मिलता है।

तीन आदतें इस गुंजाइश को छोटा रखती हैं।

ट्रांसलेशन पुल रिक्वेस्ट को खुलने के दिन ही मर्ज करें। जो पुल रिक्वेस्ट एक हफ़्ते पड़ी रहे और इस बीच Lovable दस फ़ीचर शिप कर दे, वही एकमात्र तरीका है जिससे मामला उलझ सकता है।

कैटलॉग एंट्री पर लगे रेफ़रेंस कमेंट कभी हाथ से एडिट न करें। एक्सट्रैक्शन वर्कफ़्लो #. और #: लाइनें दोबारा बना देता है, इसलिए कॉन्फ्लिक्ट सुलझाते समय अनुवादित टेक्स्ट वाली एंट्री रखें और कमेंट को अगले एक्सट्रैक्शन रन पर दोबारा लिखने दें।

मर्ज से पहले पुरानी पड़ चुकी ब्रांच को अपडेट करें। अगर पुल रिक्वेस्ट वाली ब्रांच पीछे रह गई है, तो पहले उसे अपडेट करें:

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

Git जो भी फ़्लैग करे उसे सुलझाएँ, पुश करें, और मर्ज करें। क्योंकि कैटलॉग टेक्स्ट होते हैं और हर मैसेज एक ब्लॉक होता है, आप जो कॉन्फ्लिक्ट सुलझाते हैं वह लगभग हमेशा एक एंट्री का होता है, पूरी फ़ाइल का नहीं।

ब्रांच प्रोटेक्शन से क्या बदलता है?

यह रिव्यू जोड़ता है, और रिव्यू पहले से ही यहाँ का मॉडल है। पुल रिक्वेस्ट के रूप में डिलीवर हुआ ट्रांसलेशन आपकी ब्रांच के सभी ज़रूरी चेक और अप्रूवल से गुज़रता है। प्रोटेक्टेड ब्रांच द्वारा रिजेक्ट किए गए Lovable के अपने पुश lovable-sync पर पहुँचते हैं, जिन्हें आप उसी रिव्यू से मर्ज करते हैं। दोनों रास्ते अलग हैं और कोई किसी को ब्लॉक नहीं करता।

अगर आप डिफ़ॉल्ट ब्रांच को प्रोटेक्ट करते हैं और Lovable को भी उसे एडिट करने देते हैं, तो समय-समय पर lovable-sync को मर्ज करने की उम्मीद रखें; यह Lovable का डॉक्यूमेंटेड व्यवहार है, ट्रांसलेशन की समस्या नहीं। अगर यह खटकता है, तो विकल्प हैं: Lovable के ऑथर के लिए प्रोटेक्शन नियम ढीला करना, या प्रोजेक्ट की सेटिंग्स में सिंक की जाने वाली ब्रांच को एक समर्पित ब्रांच पर ले जाना। दोनों ही स्थितियों में ट्रांसलेशन पुल रिक्वेस्ट को उसी ब्रांच पर पॉइंट करें जिसे Lovable सिंक कर रहा है।

रनटाइम ट्रांसलेशन विजेट के साथ यह सवाल क्यों नहीं उठता था?

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

यही समझौता है, और यह सही समझौता है: अनुवादित टेक्स्ट आपका अपना है, वर्ज़न्ड और इंडेक्सेबल, न कि रेंडर के समय किराये पर मिला हुआ। बस इसके लिए आपको पता होना चाहिए कि Lovable किस ब्रांच पर है। Lovable ऐप को अनुवादित रखने के दूसरे पहलू, यानी जब कैटलॉग कोड से पीछे रह जाते हैं, के लिए देखें हर शिप पर ट्रांसलेशन क्यों टूट जाते हैं। अगर आपका ऐप डेटाबेस में भी कंटेंट रखता है, तो वह लेयर रेपो के बाहर रहती है; उसके लिए Lovable ऐप में डेटाबेस कंटेंट का स्थानीयकरण देखें।

दोनों राइटर को एक ही ब्रांच पर रखें

अपने प्रोजेक्ट की GitHub सेटिंग्स में ब्रांच पिकर जाँचें, ट्रांसलेशन पुल रिक्वेस्ट को उसी ब्रांच में मर्ज करें, और lovable-sync को एरर नहीं, बल्कि टू-डू मानें। अगर आप Lovable में बना रहे हैं और चाहते हैं कि ट्रांसलेशन का काम आपको संभालना न पड़े, तो वाइब कोडर्स पेज पर पूरा ओवरव्यू है और प्राइसिंग का अपना अलग पेज है।