500+ कुंजियों के लिए Vue 3 i18n वर्कफ़्लो — प्रोडक्शन में आश्चर्य नहीं

500+ i18n कुंजियों पर क्या गलत होता है

जब आपकी ऐप कुछ सौ स्ट्रिंग्स पार कर लेती है, तो पहला टूटने वाला हिस्सा आम तौर पर Vue I18n नहीं होता। यह संगति (consistency) होती है। लोग कुंजियाँ अलग-अलग शैलियों में जोड़ते हैं, एक ही विचार के कई डुप्लिकेट बनते हैं, और किसी को भी पक्का नहीं पता होता कि कौन से मैसेज हटाए जा सकते हैं।

गायब अनुवाद भी दुर्लभ नहीं रहते। वे सामान्य यूज़र पाथ्स में दिखते हैं, खासकर कम उपयोग वाले स्क्रीन जैसे सेटिंग्स, एरर स्टेट्स, खाली स्टेट्स और नोटिफिकेशन्स में।

जब अनुवाद गायब होता है, तो उपयोगकर्ता आम तौर पर तीन में से एक समस्या देखते हैं: खाली UI (बटन पर कोई लेबल नहीं), कच्ची कुंजी दिखाई देना (जैसे checkout.pay_now), या एक अजीब फॉलबैक जहाँ पेज का हिस्सा दूसरी भाषा में दिखने लगे। ये किसी छोटे बग जैसी नहीं लगतीं — ये ऐप को टूटा हुआ दिखाती हैं।

इसीलिए Vue 3 i18n वर्कफ़्लो की अहमियत किसी विशेष लाइब्रेरी से ज़्यादा होती है। लाइब्रेरी वही करेगी जो आप कहेंगे; बड़े पैमाने पर टीमों के बीच अक्सर यह तय नहीं होता कि “किया हुआ” कैसा दिखना चाहिए।

एक आम उदाहरण: एक डेवलपर नया "Invite teammate" फ्लो भेजता है जिसमें 40 नई स्ट्रिंग्स हैं। English फ़ाइल अपडेट होती है, पर French फ़ाइल नहीं। स्टेजिंग में सब ठीक लगता है क्योंकि टेस्टर English यूज़ कर रहा था। प्रोडक्शन में French उपयोगकर्ताओं को मिश्रित ट्रांसलेटेड और अनट्रांसलेटेड UI दिखता है, और सपोर्ट को कच्ची कुंजी के स्क्रीनशॉट मिलते हैं।

इसका समाधान यह परिभाषित करना है कि ट्रांसलेटेड UI के लिए "किया हुआ" का क्या मतलब है। यह केवल "स्ट्रिंग्स जोड़ी गईं" नहीं हो सकता। एक व्यावहारिक definition of done आमतौर पर शामिल करता है: कुंजियाँ नामकरण नियमों का पालन करें, लोकल्स बिल्ड हों बिना missing-key वार्निंग्स के, बहुवचन और वेरिएबल्स असली डेटा के साथ सही तरह रेंडर हों, कम से कम एक non-default locale चेक किया गया हो, और कॉपी परिवर्तन ट्रैक हों ताकि पुरानी कुंजियाँ बरकरार न रहें।

500+ कुंजियों पर आप तब जीतते हैं जब आप लोकलाइज़ेशन को एक रिलीज़ प्रोसेस की तरह ट्रीट करते हैं, न कि आखिरी मिनट की फाइल एडिट की तरह।

नई कुंजियाँ जोड़ने से पहले कुछ नियम तय करें

कुछ सौ स्ट्रिंग्स के बाद, अनुवाद का काम गन्दा हिस्सा नहीं रहता — संगति रहती है। एक छोटा नियम सेट आपके Vue 3 i18n वर्कफ़्लो को भविष्यवाणीयोग्य बनाता है, भले ही हर हफ्ते कई लोग कॉपी छुएं।

शुरुआत में तय करें कि एक "काँसेप्ट" क्या है और उसके लिए एक स्रोत-सत्य (single source of truth) रखें। अगर एक ही UI विचार पांच जगह आता है (उदाहरण के लिए, “Save changes”), तो आप एक ही कुंजी चाहेंगे, न कि save, saveChanges, save_update, और saveBtn जैसे पाँच वेरिएंट। डुप्लिकेट कुंजियाँ समय के साथ अर्थ में भटक जाती हैं, और उपयोगकर्ताओं को वह असंगति महसूस होती है।

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

एक व्यावहारिक डिफ़ॉल्ट:

• व्याकरण, विराम और उपयोगकर्ता-समक्ष फ़ॉर्मैटिंग (जैसे “(optional)”) संदेश में रखें।
• शुद्ध डेटा फ़ॉर्मैटिंग को कोड में रखें (तिथियाँ, मुद्रा, इकाइयाँ), फिर परिणाम i18n में पास करें।
• नामों और गिनती के लिए प्लेसहोल्डर इस्तेमाल करें, स्ट्रिंग concatenation नहीं।
• संदेशों में HTML को एक विशेष केस के रूप में मानें और एक स्पष्ट नियम रखें (अनुमत है या नहीं)।

फिर मालिकाना तय करें। तय करें कि कौन नई कुंजियाँ जोड़ सकता है, बेस-भाषा कॉपी को कौन रिव्यू करता है, और अन्य लोकल्स को कौन अप्रूव करता है। इसके बिना, स्ट्रिंग्स जल्दबाजी में जुड़ जाती हैं और कभी रिव्यू नहीं होतीं।

अंत में, एक फॉलबैक स्ट्रैटेजी चुनें और डॉक्यूमेंट करें। अगर कोई कुंजी गायब है तो उपयोगकर्ताओं को क्या दिखाना चाहिए: कुंजी नाम, डिफ़ॉल्ट-लोकल का टेक्स्ट या एक सुरक्षित जनरिक मैसेज? प्रोडक्शन में कई टीमें डिफ़ॉल्ट लोकल पर फॉलबैक और लॉगिंग को पसंद करती हैं, ताकि उपयोगकर्ता ब्लॉक न हों पर आप को संकेत मिल सके कि कुछ ग़लत है।

यदि आप AppMaster जैसे जनरेटर के साथ Vue 3 ऐप बनाते हैं (Vue3 web UI और असली बैकएंड कोड के साथ), तो ये नियम अभी भी लागू होते हैं। ट्रांसलेशंस को प्रोडक्ट कंटेंट की तरह ट्रीट करें, सिर्फ "डेव टेक्स्ट" की तरह नहीं, और आप ज्यादातर देर से होने वाली आश्चर्यों से बचेंगे।

पढ़ने योग्य बने रहने वाले की-नामकरण कन्वेंशन्स

कुछ सौ स्ट्रिंग्स के बाद, संगति सबसे बड़ा गुणा बन जाती है। एक की शैली चुनें (अधिकतर टीमें dot paths जैसे billing.invoice.title इस्तेमाल करती हैं) और इसे नियम बनाएं। डॉट, स्लैश, snake_case और रैंडम केस मिलाने से सर्च और रिव्यू स्लो हो जाते हैं।

ऐसी स्थिर कुंजियाँ इस्तेमाल करें जो कॉपी परिवर्तन सह सकें। "Please enter your email" जैसी कुंजी जैसे ही मार्केटिंग वाक्य बदलती है, टूट जाएगी। इंटेंट-आधारित नाम पसंद करें जैसे auth.email.required या auth.email.invalid।

पहले प्रोडक्ट एरिया या UI सतह के हिसाब से कुंजियाँ ग्रुप करें, फिर उद्देश्य के हिसाब से। उसी बकेट में सोचें जो आपकी ऐप पहले से इस्तेमाल करती है: auth, billing, settings, support, dashboard। इससे लोकल फ़ाइलें स्कैन करने में आसान रहती हैं और दो स्क्रीन जब एक ही विचार चाहती हैं तो डुप्लिकेट कम होते हैं।

प्रत्येक एरिया के भीतर, सामान्य UI हिस्सों के लिए एक छोटा पैटर्न सेट रखें:

• Buttons: *.actions.save, *.actions.cancel
• Labels: *.fields.email.label, *.fields.password.label
• Hints/help text: *.fields.email.hint
• Errors/validation: *.errors.required, *.errors.invalidFormat
• Notifications/toasts: *.notices.saved, *.notices.failed

डायनामिक संदेशों को बताना चाहिए कि क्या बदल रहा है, कैसे नहीं। मैसेज को इरादे से नाम दें और वेरिएबल हिस्सों के लिए पैरामीटर इस्तेमाल करें। उदाहरण के लिए, billing.invoice.dueInDays के साथ {days} उस से बेहतर है कि billing.invoice.dueIn3Days।

उदाहरण (Vue 3 i18n वर्कफ़्लो में अच्छा काम करता है): orders.summary.itemsCount के साथ {count} संख्या के लिए, और orders.summary.total {amount} के साथ पैसे के लिए। जब कोई कोड में कुंजी पढ़े, तो उसे पता होना चाहिए कि यह कहाँ है और क्यों है, भले ही अंतिम कॉपी बाद में बदल जाए।

बिना आश्चर्य के बहुवचन नियम और मैसेज फ़ॉर्मैटिंग

यदि आप हर भाषा को अंग्रेज़ी जैसा मानते हैं तो बहुवचन (plural) टेक्स्ट चुपचाप टूट जाता है। जल्द ही तय करें कि आप कब ICU मैसेज सिंटैक्स उपयोग करेंगे और कब साधारण प्लेसहोल्डर काफी होगा।

लेबल्स और छोटे UI टेक्स्ट के लिए जो संख्या से बदलते ही नहीं (उदाहरण: "Welcome, {name}"), सरल रिप्लेसमेंट का उपयोग करें। किसी भी count-आधारित टेक्स्ट के लिए ICU का इस्तेमाल करें, क्योंकि यह सभी रूपों को एक जगह रखता है और नियम स्पष्ट करता है。

{
  "notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}

काउंट मैसेज ऐसे लिखें कि वे अनुवाद के लिए आसान हों। पूरा वाक्य पसंद करें और संख्या प्लेसहोल्डर (#) को संज्ञा के पास रखें। चतुर शॉर्टकट जैसे "1 item" और "2 items" के लिए एक ही कुंजी का कोड में पुनरुपयोग करने से बचें। अनुवादकों को पूरा मैसेज दिखना चाहिए, न कि यह अनुमान लगाना कि उसे कैसे जोड़ा जाएगा।

कम से कम =0, one, और other के लिए योजना बनाएं, और यह डॉक्यूमेंट करें कि आप 0 के लिए क्या उम्मीद करते हैं। कुछ प्रोडक्ट्स "0 items" चाहते हैं, अन्य "No items" चाहते हैं। एक स्टाइल चुनें और उस पर कायम रहें ताकि UI सुसंगत लगे।

साथ ही उन भाषाओं के लिए सावधान रहें जिनमें आपकी उम्मीद से अधिक plural कैटेगरी होती हैं। कई भाषाएँ "one vs many" का पालन नहीं करतीं। यदि आप बाद में कोई नया लोकल जोड़ते हैं, तो केवल one और other वाली संदेश व्याकरणिक रूप से गलत हो सकती है भले ही वह रेंडर हो रही हो।

शिप करने से पहले UI में असली काउंट्स के साथ plurals टेस्ट करें, सिर्फ JSON देखकर नहीं। एक त्वरित चेक जो ज्यादातर समस्याएँ पकड़ता है वह है: 0, 1, 2, 5, और 21।

यदि आप Vue3 वेब ऐप बनाते हैं (उदाहरण के लिए AppMaster के अंदर), तो यह टेस्ट उसी स्क्रीन पर करें जहाँ टेक्स्ट दिखाई देता है। लेआउट समस्याएँ, कटे हुए टेक्स्ट और अजीब वाक्य वहाँ सबसे पहले दिखते हैं।

वृद्धि के लिए लोकल फ़ाइलों का आयोजन

कुछ सौ स्ट्रिंग्स के बाद, एक बड़ा en.json बॉटलनेक बन जाता है। लोग एक ही फ़ाइल छूते हैं, मर्ज कॉन्फ्लिक्ट बढ़ते हैं, और आप खो देते हैं कि कॉपी कहाँ रहती है। एक अच्छा स्ट्रक्चर आपका Vue 3 i18n वर्कफ़्लो स्थिर रखता है भले ही प्रोडक्ट बदलता रहे।

सुझाए गए स्ट्रक्चर्स

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

• locales/en/common.json, locales/en/auth.json, locales/en/billing.json
• locales/es/common.json, locales/es/auth.json, locales/es/billing.json
• locales/index.ts (messages लोड और मर्ज करता है)

20+ लोकल्स के लिए, वही विचार बढ़ाएँ पर ड्रिफ्ट को मुश्किल बनाएं। English को स्रोत के रूप में ट्रीट करें और हर लोकल के लिए वही फ़ोल्डर और फ़ाइल नाम मिरर हो ये एन्फोर्स करें। अगर कोई नया डोमेन आता है (उदाहरण: notifications), तो वह हर लोकल में मौजूद होना चाहिए भले ही टेक्स्ट अस्थायी हो।

डोमेन द्वारा स्प्लिट करने से मर्ज कॉन्फ्लिक्ट कम होते हैं क्योंकि दो लोग अलग फ़ाइलों में स्ट्रिंग्स जोड़ सकते हैं बिना एक दूसरे पर कदम रखे। डोमेन को आपकी ऐप के बिल्ड के तरीके से मिलना चाहिए: common, navigation, errors, settings, reports, और बड़े एरियाज के लिए फीचर फ़ोल्डर्स।

कुंजियों की संगति बनाए रखना

हर फ़ाइल के भीतर, लोकल्स में वही की-शेप रखें: वही नेस्टिंग, वही की-नाम, अलग-अलग टेक्स्ट। हर भाषा में "क्रिएटिव" कुंजियाँ टालें, भले ही कोई वाक्य अनुवाद के लिए कठिन हो। अगर English में billing.invoice.status.paid चाहिए, तो हर लोकल में वही कुंजी होनी चाहिए।

सिर्फ वही चीज़ें सेंट्रलाइज़ करें जो वास्तव में हर जगह दोहराई जाती हैं: बटन लेबल, सामान्य वैलिडेशन एरर्स, और ग्लोबल नेविगेशन। फीचर-स्पेसिफिक कॉपी को फीचर डोमेन के पास ही रखें, भले ही वह पुन: प्रयोज्य लगे। “Save” common में रहेगा। “Save payment method” billing में रहेगा।

लंबा-फॉर्म कंटेंट

लंबे हेल्प टेक्स्ट, ऑनबोर्डिंग स्टेप्स, और ईमेल टेम्पलेट्स जल्दी गड़बड़ हो जाते हैं। कुछ नियम मदद करते हैं:

• लंबा-फॉर्म स्ट्रिंग्स को अपने डोमेन में रखें (उदाहरण: help या onboarding) और गहरी नेस्टिंग से बचें।
• ट्रांसलेटर्स के लिए छोटे पैराग्राफ़ रखें बजाय एक बड़े स्ट्रिंग के।
• अगर मार्केटिंग या सपोर्ट अक्सर एडिट करता है, तो उन मैसेज को अलग फ़ाइल में रखें ताकि दूसरों पर चर्न कम हो।
• ईमेल के लिए, सब्जेक्ट और बॉडी अलग रखें और प्लेसहोल्डर्स एक समान रखें (नाम, तिथियाँ, रकम)।

यह सेटअप बदलावों की समीक्षा, steady translation और रिलीज़ के ठीक पहले आश्चर्यजनक अंतराल से बचने में आसान बनाता है।

नई स्ट्रिंग्स जोड़ने और शिप करने के लिए स्टेप-बाय-स्टेप वर्कफ़्लो

एक स्थिर Vue 3 i18n वर्कफ़्लो टूल्स से ज्यादा छोटे-छोटे दोहराए जाने वाले कदमों के बारे में है। नई UI टेक्स्ट को बिना कुंजी, डिफ़ॉल्ट मैसेज और स्पष्ट अनुवाद स्थिति के प्रोडक्शन में नहीं पहुँचाना चाहिए।

शुरू करें बेस लोकल में कुंजी जोड़कर (अक्सर en)। डिफ़ॉल्ट टेक्स्ट असली कॉपी जैसा लिखें, प्लेसहोल्डर नहीं। इससे प्रोडक्ट और QA के पास कुछ पढ़ने को होगा और बाद में "रहस्यमयी स्ट्रिंग्स" नहीं बनेंगी।

जब आप किसी कॉम्पोनेंट में कुंजी का उपयोग करें, तो params और plural लॉजिक पहले दिन से शामिल करें ताकि अनुवादक पूरा मैसेज देख सकें।

// simple param
$t('billing.invoiceDue', { date: formattedDate })

// plural
$t('files.selected', count, { count })

यदि अनुवाद तैयार नहीं हैं, तो कुंजियाँ खाली न छोड़े। अन्य लोकल्स में प्लेसहोल्डर अनुवाद जोड़ें या उन्हें सामंजस्यपूर्ण तरीके से pending मार्क करें (उदाहरण के लिए, मान को TODO: से प्रिफिक्स करें)। महत्वपूर्ण हिस्सा यह है कि ऐप प्रेडिक्टेबल रूप से रेंडर हो और रिव्यू करने वाले अधूरे कॉपी को पहचान सकें।

मर्ज करने से पहले, त्वरित ऑटोमैटेड चेक चलाएँ। इन्हें नीरस पर सख्त रखें: लोकल्स में missing keys, unused keys, placeholder mismatch (लापता {count}, {date}, या गलत ब्रेसेस), समर्थित भाषाओं के लिए अमान्य plural फॉर्म, और आकस्मिक ओवरराइड्स।

अंत में, कम से कम एक non-base लोकल में छोटा UI पास करें। लंबी स्ट्रिंग्स वाले भाषा (अक्सर German या French) चुनें ताकि overflow, कटते बटन और अजीब लाइन ब्रेक पकड़े जा सकें। यदि आपकी Vue 3 UI किसी जनरेटर या अन्य प्रोडक्ट हिस्सों के साथ बनाई जाती है (उदाहरण: AppMaster), तो यह कदम तब भी मायने रखता है क्योंकि लेआउट फीचर्स बदलने पर बदलते हैं।

इन स्टेप्स को किसी भी फीचर के लिए आपका definition of done मानें जो टेक्स्ट जोड़ता है।

टीमें जो बार-बार जारी रखने वाली आम गलतियाँ

लोकलाइज़ेशन को कष्टप्रद बनाने का सबसे तेज़ तरीका है i18n कुंजियों को बस "स्ट्रिंग्स" की तरह ट्रीट करना। कुछ सौ कुंजियों के बाद, छोटे आदतें प्रोडक्शन बग बन जाती हैं।

कुंजियाँ जो भटकती हैं, टकराती हैं, या झूठ बोलती हैं

टाइपो और केस अंतर missing टेक्स्ट के क्लासिक कारण हैं: एक जगह checkout.title, दूसरी जगह Checkout.title। कोड रिव्यू में यह ठीक दिखता है, फिर आपका फॉलबैक भाषा चुपचाप शिप हो जाती है।

एक और आम समस्या एक ही कुंजी को अलग अर्थों के लिए पुन: उपयोग करना है। “Open” समर्थन स्क्रीन पर “Open ticket” मतलब दे सकता है और स्टोर पेज पर “Open now” का मतलब। अगर आप एक ही कुंजी पुन: उपयोग करते हैं तो दूसरी स्क्रीन गलत होगी अन्य भाषाओं में, और अनुवादक अनुमान लगाएंगे।

एक सरल नियम मदद करता है: एक कुंजी = एक अर्थ। अगर अर्थ बदलता है, तो नई कुंजी बनाएं भले ही English टेक्स्ट वही हो।

"स्ट्रिंग-आकार" अनुमानों से होने वाली लेआउट बग्स

टीम अक्सर विराम, स्पेसिंग, या HTML के टुकड़ों को अनुवादों में हार्डकोड कर देती हैं। यह तब काम करता है जब तक किसी भाषा को अलग विराम की ज़रूरत न हो, या आपका UI मार्कअप को अलग तरह से escape या रेंडर न करे। मार्कअप निर्णय टेम्पलेट्स में रखें और मैसेज को टेक्स्ट पर केंद्रित रखें।

मोबाइल वह जगह है जहाँ समस्याएँ छिपती हैं। English में फिट होने वाला लेबल German में तीन लाइनों में लपेट सकता है, या Thai में overflow कर सकता है। अगर आप केवल एक स्क्रीन साइज टेस्ट करते हैं, तो आप इसे मिस करेंगे।

दोबारा जांचें: English शब्द क्रम पर मान लेना जब वेरिएबल्स (नाम, गिनती, तिथियाँ) डाले जाते हैं, टुकड़ों को जोड़कर संदेश बनाना बजाय एक ही संदेश के, लंबी वैल्यूज़ (प्रोडक्ट नाम, एड्रेस, एरर डिटेल्स) का परीक्षण न करना, साइलेंट फॉलबैक के साथ शिप करना ताकि गायब कुंजियाँ English में "ठीक" दिखें, और केवल English वैल्यू एडिट करते समय कुंजी को कॉपी-पेस्ट करना।

यदि आप चाहते हैं कि 500+ कुंजियों पर आपका Vue 3 i18n वर्कफ़्लो शांत रहे, तो कुंजियों को अपने API का हिस्सा मानें: स्थिर, विशेष और अन्य चीजों की तरह टेस्ट किए गए।

गायब अनुवाद जल्दी पकड़ने वाले QA स्टेप्स

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

ऑटोमेटेड चेक्स (हर PR पर चलाएँ)

बिल्ड को फेल करने वाले चेक्स से शुरू करें, उन वॉर्निंग्स से नहीं जिन्हें कोई नहीं देखता।

• कोडबेस में $t('...') और t('...') उपयोग स्कैन करें, फिर पुष्टि करें कि हर उपयोग की गई कुंजी बेस लोकल में मौजूद है।
• लोकल्स के बीच की-सेट की तुलना करें और फेल करें अगर कोई लोकल्स कीज़ गायब हैं (जब तक कुंजी किसी छोटी, रिव्यू की गई exception list जैसे "en-only legal notes" में नहीं हो)।
• orphan कुंजियों को फ़्लैग करें जो लोकल फ़ाइलों में हैं पर कभी उपयोग नहीं होतीं।
• मैसेज सिंटैक्स मान्य करें (प्लेसहोल्डर्स, ICU/plural ब्लॉक्स)। एक भी टूटी हुई मैसेज रनटाइम पर पेज क्रैश कर सकती है।
• डुप्लिकेट कुंजियाँ या असंगत केसिंग को एरर मानें।

एक्सेप्शन लिस्ट छोटी रखें और टीम की जिम्मेदारी पर हो, न कि "जो भी CI पास हो" पर।

रनटाइम और विज़ुअल चेक्स (स्टेजिंग)

CI के साथ भी, स्टेजिंग में एक नेट चाहिए क्योंकि असली यूज़र पाथ्स वे स्ट्रिंग्स ट्रिगर करते हैं जिन्हें आप भूल गए थे।

स्टेजिंग में missing-translation लॉगिंग चालू करें और फिक्स करने के लिए पर्याप्त संदर्भ शामिल करें: लोकल, रूट, कॉम्पोनेंट नाम (यदि उपलब्ध), और missing key। इसे noisy बनाएं। अगर इसे नजरअंदाज करना आसान होगा, तो वह हो जाएगा।

एक pseudo-locale जोड़ें और इसे एक त्वरित UI पास के लिए इस्तेमाल करें। एक सरल तरीका यह है कि हर स्ट्रिंग को ट्रांसफॉर्म करें (इसे लंबा और मार्कर्स जोड़ें) ताकि लेआउट समस्याएँ तुरंत दिखें, उदाहरण: [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲𝗱 !!!]। यह कटे बटन, टूटी टेबल हेडर और मिसिंग स्पेसिंग पकड़ता है।

अंत में, अपनी सबसे महत्वपूर्ण फ्लोज़ में 2-3 लोकल्स में छोटा प्री-रिलीज़ spot check करें: साइन-इन, चेकआउट/पेमेंट, कोर सेटिंग्स, और जो नया फीचर आप रिलीज़ कर रहे हैं। यहीं आप "यह अनुवादित था पर प्लेसहोल्डर गलत है" बग पकड़ते हैं।

नई भाषाओं और लगातार होने वाले कॉपी परिवर्तनों को हैंडल करना

नई भाषा जोड़ना गन्दा हो जाता है जब आप उसे "कॉपी काम" की तरह ट्रीट करते हैं न कि एक छोटे प्रोडक्ट रिलीज़ की तरह। सबसे आसान तरीका अपने Vue 3 i18n वर्कफ़्लो को स्थिर रखने का यह है कि ऐप बिल्ड करे भले ही एक लोकल अधूरा हो, पर अंतर स्टेजिंग में स्पष्ट हों।

नई लोकल जोड़ते समय, स्रोत लोकल (अकसर en) जैसा ही फ़ाइल शेप जेनरेट करके शुरू करें। पहले अनुवाद न करें, स्ट्रक्चर पहले करें।

• नया लोकल फ़ोल्डर/फ़ाइल बनाएं और स्रोत से पूरा की सेट कॉपी करें।
• वैल्यूज़ को TODO प्लेसहोल्डर के रूप में मार्क करें ताकि QA में अधूरे स्ट्रिंग्स दिखाई दें।
• भाषा स्विचर में नया लोकल तभी जोड़ें जब बेसिक कवर हो।
• स्क्रीन-बाय-स्क्रीन पास चलाएँ ताकि लेआउट समस्याएँ (लंबे शब्द, रैपिंग) पकड़ी जा सकें।

अनुवाद अक्सर देर से आते हैं, इसलिए पहले से तय कर लें कि "आंशिक" का मतलब क्या है आपके प्रोडक्ट के लिए। यदि कोई फीचर कस्टमर-फेसिंग है, तो फीचर-फ्लैग पर विचार करें ताकि फीचर और उसकी स्ट्रिंग्स साथ में शिप हों। अगर आपको बिना पूर्ण अनुवाद के शिप करना है, तो खाली लेबल के बजाय क्लियर फॉलबैक (जैसे English) चुनें, पर इसे स्टेजिंग में ज़ोरदार बनाएं।

कॉपी अपडेट्स वह जगह हैं जहाँ टीमें कुंजियों को तोड़ती हैं। अगर आप वर्डिंग बदलते हैं, तो कुंजी स्थिर रखें। कुंजियाँ इरादे का वर्णन करें, न कि ठीक वाक्य। कुंजी का नाम बदलना तब ही करें जब अर्थ बदले, और तब भी कंट्रोल्ड माइग्रेशन के साथ करें।

"ज़ोंबी स्ट्रिंग्स" से बचने के लिए कुंजियों को जानबूझकर डिप्रिकेट करें: कुंजी को एक तारीख और रिप्लेसमेंट के साथ डिप्रिकेट मार्क करें, एक रिलीज़ साइकल के लिए रखें, फिर हटाएँ केवल जब आप पुष्टि कर लें कि कहीं रेफरेंस नहीं है।

ट्रांसलेशन नोट्स को कुंजी के पास रखें। अगर आपका JSON फ़ॉर्मैट कमेंट्स नहीं रख सकता, तो छोटे साथी डॉक्यूमेंट या सटे हुए मेटाडेटा फ़ाइल में नोट्स स्टोर करें (उदाहरण: "checkout success screen पर उपयोग होता है")। यह खासकर तब मददगार है जब आपकी Vue 3 वेब ऐप AppMaster जैसे टूल से जेनरेट हो और कई लोग कॉपी और UI छूते हों।

उदाहरण: 60 नई स्ट्रिंग्स के साथ एक फीचर भेजना

एक स्प्रिंट में टीम एक साथ तीन चीजें भेजती है: एक नया Settings पेज, एक Billing स्क्रीन, और तीन ईमेल टेम्पलेट्स (receipt, payment failed, trial ending)। यह लगभग 60 नई स्ट्रिंग्स है, और यहीं से गंदा i18n आम तौर पर शुरू होता है।

टीम फ़ीचर के हिसाब से कुंजियाँ ग्रुप करने पर सहमत होती है, फिर सतह के हिसाब से। हर फीचर के लिए नई फ़ाइल बनाई जाती है, और कुंजियाँ हर जगह वही पैटर्न फॉलो करती हैं: feature.area.element।

// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",

// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",

// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"

ट्रांसलेशन वर्क शुरू होने से पहले, plural स्ट्रिंग्स असली वैल्यूज़ के साथ टेस्ट की जाती हैं, अनुमान के साथ नहीं। billing.invoice.count के लिए QA 0, 1, 2, और 5 चेक करता है (सीडेड डेटा या साधारण डेव टॉगल से)। इससे समय पर अजीब केस पकड़े जाते हैं, जैसे "0 invoice"।

QA फिर उन केंद्रित फ्लोज़ को चलाती है जो गायब कुंजी उजागर करते हैं: Settings और Billing खोलें और हर टैब पर एक बार क्लिक करें, स्टेजिंग में टेस्ट अकाउंट से हर ईमेल टेम्पलेट ट्रिगर करें, एक non-default लोकल के साथ ऐप चलाएँ, और अगर लॉग्स में कोई missing-translation वार्निंग दिखे तो बिल्ड फेल करें।

इस स्प्रिंट में, QA को दो गायब कुंजियाँ मिलती हैं: Billing स्क्रीन पर एक लेबल और एक ईमेल सब्जेक्ट। टीम उन्हें रिलीज़ से पहले ठीक कर देती है।

रिलीज़ ब्लॉक करना या फॉलबैक की अनुमति देने का निर्णय वे एक सरल नियम से करते हैं: यूज़र-फेसिंग स्क्रीन और ट्रांज़ैक्शनल ईमेल रिलीज़ ब्लॉक करते हैं; कम-जोखिम एडमिन-ओनली टेक्स्ट अस्थायी रूप से डिफ़ॉल्ट भाषा पर फॉलबैक कर सकता है, पर केवल एक टिकट और स्पष्ट डेडलाइन के साथ।

अगले कदम और एक साधारण रिलीज़ चेकलिस्ट

जब आप ट्रांसलेशंस को कोड की तरह ट्रीट करेंगे — हर बार समान तरीके से जोड़ना, टेस्ट करना और स्कोर रखना — तो Vue 3 i18n वर्कफ़्लो स्थिर रहेगा।

रिलीज़ चेकलिस्ट (मर्ज से 5 मिनट पहले)

• Keys: अपने नामकरण पैटर्न का पालन करें, और स्कोप स्पष्ट रखें (पेज, फीचर, कॉम्पोनेंट)।
• Plurals: कम से कम एक भाषा में पुष्ट करें कि plural फॉर्म सही रेंडर होते हैं जिसमें कई plural नियम हों।
• Placeholders: वेरिएबल मौजूद हों, हर जगह एक जैसे नाम हों, और असली डेटा के साथ सही दिखें।
• Fallbacks: सुनिश्चित करें कि missing-key व्यवहार आपकी वर्तमान नीति के अनुरूप है।
• Screens: कुछ स्क्रीन स्पॉट-चेक करें जो टूटने की संभावना रखते हैं (टेबल्स, टूस्ट, मॉडलों, खाली स्टेट्स)।

मापने के लिए क्या तय करें (ताकि समस्याएँ जल्दी दिखें)

कुछ सरल मेट्रिक्स चुनें और नियमित रूप से उनकी समीक्षा करें: टेस्ट रन में missing-key दर, नॉन-डिफ़ॉल्ट लोकल्स में अनुवादित न हुए स्ट्रिंग्स की संख्या, और unused key count (वे स्ट्रिंग्स जो अब किसी जगह नहीं दिखतीं)। इन्हें रिलीज़ के अनुसार ट्रैक करें ताकि आप ट्रेंड देख सकें न कि केवल एक-बार की गड़बड़ी।

नई स्ट्रिंग जोड़ने, ट्रांसलेशंस अपडेट करने, और परिणाम सत्यापित करने के सटीक कदम लिख लें। इसे छोटा रखें और कुंजी-नामों व plural उपयोग के उदाहरण शामिल करें। नए योगदानकर्ता बिना पूछे इसे फॉलो कर सकें।

यदि आप आंतरिक टूल बनाते हैं, तो AppMaster (appmaster.io) एक व्यावहारिक तरीका हो सकता है ताकि Vue3 वेब ऐप और सहायक मोबाइल ऐप्स में UI कॉपी और ट्रांसलेशन कुंजियाँ सुसंगत रहें, क्योंकि सब कुछ एक ही जगह प्रबंधित होता है।

हर स्प्रिंट में एक छोटा i18n हेल्थ टास्क शेड्यूल करें: डेड कीज़ हटाएँ, असंगत प्लेसहोल्डर्स ठीक करें, और हाल के मिसेस की समीक्षा करें। छोटे क्लीनअप आपातकालीन अनुवाद शिकारों से बेहतर हैं।