वेब और नेटिव UI के लिए भरोसेमंद लोकलाइज़ेशन वर्कफ़्लो

जब लोकलाइज़ेशन अनमैनेज्ड हो तो क्या गलत होता है

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

अधिकतर टीमें दबाव के नीचे एक ही समस्याएँ बार-बार ठीक करती हैं:

• कटी हुई बटन, छूटे हेडर, या आइकन पर ओवरलैप होता टेक्स्ट
• गायब कीज़ जो अंग्रेज़ी पर fallback कर देती हैं या की का नाम दिखाती हैं
• गलत बहुवचन रूप (उदाहरण: "1 items") और जेंडर-आधारित भाषाओं में टूटे हुए व्याकरण
• एक ही अवधारणा के लिए स्क्रीन-भर में असंगत शब्दावली
• अंतिम समय की हॉटफिक्स क्योंकि एक स्क्रीन अनुवादों के बिना शिप हो गई

वेब और नेटिव स्क्रीन अक्सर अलग-अलग तरीकों से फेल होती हैं। वेब पर फ्लेक्सिबल लेआउट समस्याओं को छिपा सकते हैं जब तक कि कोई खास व्यूपोर्ट या ब्राउज़र उन्हें उजागर न करे। टेक्स्ट अनपेक्षित रूप से रैप कर सकता है, बटन को नीचे धक्का दे सकता है, या ग्रिड तोड़ सकता है। नेटिव ऐप्स में spacing अधिक सख्त होता है। लंबा अनुवाद महत्वपूर्ण एलिमेंट्स को स्क्रीन से बाहर धकेल सकता है, एक्सेसिबिलिटी फ़ॉन्ट साइज़ के साथ टकरा सकता है, या कट सकता है क्योंकि कोई कंपोनेंट ऑटो-रिसाइज़ नहीं करता।

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

सफलता की साधारण परिभाषा "सब कुछ अनुवादित है" नहीं है। यह है:

• UI वेब और नेटिव स्क्रीन पर पठनीय बनी रहे
• कीज़ जल्दी अपडेट हों क्योंकि वे लगातार बदलती नहींं हैं
• QA यूज़र से पहले समस्याएँ पकड़ ले

उदाहरण: अगर एक कार्ट स्क्रीन "{count} item(s)" दिखाती है, तो अनमैनेज्ड स्ट्रिंग्स का परिणाम अजीब बहुवचन और टूटती हुई जगह हो सकता है। एक मैनेज्ड अप्रोच सही बहुवचन नियम लागू कराती है और रिलीज़ से पहले उस बटन को पकड़ लेती है जो जर्मन में 30% बड़ा हो जाता है।

मालिकाना तय करें और एक सिंगल सोर्स ऑफ ट्रुथ चुनें

लोकलाइज़ेशन वर्कफ़्लो सबसे जल्दी तब टूटता है जब कोई व्यक्ति इस सवाल का जवाब नहीं दे पाता: “असली टेक्स्ट कौन सा है?” स्ट्रिंग्स के लिए एक सिंगल सोर्स ऑफ ट्रुथ चुनें और इसे निर्विवाद रूप से साफ़ कर दें। वह स्रोत कोई रेपो फाइल, ट्रांसलेशन प्लेटफ़ॉर्म, या एक आंतरिक टेबल हो सकता है, पर यह एक जगह होनी चाहिए जो हर विवाद को जिता दे।

रोल्स को नौकरी के टाइटल से नहीं बल्कि निर्णयों से परिभाषित करें। किसी को अर्थ और टोन Approve करना चाहिए (अक्सर Product या Marketing)। किसी को कीज़ को कोड में स्थिर और उपयोग योग्य रखना चाहिए (अक्सर Engineering)। किसी को UI पाबंदियाँ संरक्षित करनी चाहिए (अक्सर Design), खासकर जब वेब और नेटिव स्क्रीन अलग ढंग से व्यवहार करते हैं।

एक विभाजन जो अधिकांश संघर्ष टालता है:

• की बनाने वाला: स्क्रीन शिप करने वाला व्यक्ति नई कीज़ बनाता है जब UI को नए टेक्स्ट की ज़रूरत हो।
• वर्डिंग Approver: PM या कॉपी मालिक बेस भाषा पर अंतिम मंजूरी देता है।
• अनुवाद संपादक: अनुवादक अनुवाद बदल सकते हैं, लेकिन कीज़ का नाम नहीं बदल सकते।
• की परिवर्तन: केवल की मालिक ही कीज़ को डिप्रिकेट या मर्ज कर सकता है, और क्यों किया इसका नोट छोड़ना चाहिए।

रिलीज़ अटक न जाएँ इसलिए प्रतिक्रिया समय की अपेक्षाएँ सेट करें। उदाहरण के लिए: नई की रिक्वेस्ट 1 बिज़नेस डे में acknowledge, स्रोत वर्डिंग 2 दिनों में approve, और क्रिटिकल फ़िक्स (टूटी UI, गलत लीगल टेक्स्ट) कुछ घंटों में।

कंक्रीट उदाहरण: आपकी टीम एक नया “Reset password” फ्लो बनाती है जिसमें वेब और नेटिव दोनों स्क्रीन हों। डेवलपर कीज़ जोड़ता है, PM अंग्रेज़ी टेक्स्ट approve करता है, और अनुवादक दूसरी भाषाएँ भरते हैं। अगर अनुवादक देखता है कि “Reset” को “Change” होना चाहिए, तो वे अनुवाद अपडेट करते हैं, लेकिन की वही रहती है। अगर PM चाहता है कि टेक्स्ट स्क्रीन-भर reuse हो, तो केवल की मालिक वह स्ट्रक्चरल बदलाव करे ताकि कुछ अनजाने में टूटे नहीं।

की स्ट्रेटेजी: पुन:उपयोग, स्थिरता और स्क्रीन सीमाएँ

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

जब अर्थ अलग हो तो नई की बनाएं। जब अर्थ वही हो तो की का पुन:उपयोग करें, भले ही स्क्रीन अलग हो। प्रोफ़ाइल स्क्रीन पर "Save" और सेटिंग्स स्क्रीन पर "Save" एक ही की शेयर कर सकते हैं अगर दोनों का मतलब “बदलाव सुरक्षित करें” ही हो। पर अगर "Save" का मतलब "बुकमार्क" है तो अलग की होनी चाहिए, क्योंकि अनुवादक को अलग क्रिया चाहिए होगी।

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

प्लेटफ़ॉर्म भिन्नता बिना एकसमान वाक्यविन्यास थोपना

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

एक व्यावहारिक पैटर्न है: फीचर और UI प्रकार के अनुसार कीज़ ग्रुप करें, फिर उन सीमाओं के भीतर reuse करें:

• उसी फीचर के अंदर वही अर्थ हो तो पुन:उपयोग करें
• UI प्रकार के अनुसार कीज़ अलग रखें (label vs help vs error vs system prompt)
• केवल तब प्लेटफ़ॉर्म वेरिएंट उपयोग करें जब वाक्यविन्यास अलग होना ज़रूरी हो
• कीज़ को स्थिर रखें और केवल डिस्प्ले टेक्स्ट बदलें
• संदर्भ नोट जोड़ें (कहाँ दिखाई देती है, कैरेक्टर लिमिट)

उदाहरण के लिए, वही “Delete customer” क्रिया वेब एडमिन पैनल और नेटिव फील्ड ऐप में मौजूद हो सकती है। आप कोर एक्शन लेबल reuse कर सकते हैं, पर नेटिव कन्फर्मेशन टेक्स्ट के लिए अलग की रख सकते हैं अगर उसे मजबूत चेतावनी या छोटे लाइनों की ज़रूरत हो।

अनुवाद कुंजियों का नामकरण और संगठन

एक अच्छा नामकरण सिस्टम लोकलाइज़ेशन को सर्वश्रेष्ठ तरीके से नीरस बना देता है: लोग स्ट्रिंग्स तेज़ी से ढूँढ लें, अनुवादक को संदर्भ मिले, और कीज़ स्थिर रहें भले ही कॉपी बदले।

ऐसी पठनीय कन्‍वेंशन उपयोग करें जो चार सवालों का जवाब दे: यह कहाँ है, क्या है, किसलिए है, और क्या यह वेरिएंट है। एक सरल पैटर्न जो वेब और नेटिव दोनों पर काम करता है:

\u003cproduct_or_domain\u003e.\u003cscreen_or_flow\u003e.\u003ccomponent\u003e.\u003cpurpose\u003e[.\u003cvariant\u003e]

उदाहरण के लिए, कस्टमर पोर्टल में: portal.login.button.submit या portal.orders.empty_state.title। इससे कीज़ स्क्रीन या फ़्लो के अनुसार ग्रुप रहेंगी और कंपोनेंट से खोजना आसान होगा।

खराब कीज़ या तो बहुत अस्पष्ट होती हैं या वर्तमान अंग्रेज़ी टेक्स्ट से बहुत जुड़ी होती हैं:

• अच्छा: portal.profile.field.email.label
• बुरा: emailText (कोई स्कोप नहीं, कोई इरादा नहीं)
• बुरा: please_enter_your_email (जब कॉपी बदले तो टूट जाएगा)
• अच्छा: portal.checkout.error.payment_failed
• बुरा: error_12

वेरिएंट स्पष्ट होने चाहिए, पंक्चुएशन या मिक्स्ड केस से छेड़छाड़ नहीं। अगर मोबाइल हेडर के लिए छोटा लेबल चाहिए, तो वेरिएंट सफ़िक्स जोड़ें: ...title.short vs ...title.long। अगर केस भेद चाहिए, तो केवल तब अलग की बनाएं जैसे ...button.save और ...button.save_titlecase जब प्लेटफ़ॉर्म टेक्स्ट को सुरक्षित रूप से ट्रांसफॉर्म नहीं कर सकता।

प्लेसहोल्डर्स के लिए भी नियम चाहिए ताकि अनुवादक अनुमान न लगाएँ।

• नामित प्लेसहोल्डर्स उपयोग करें: {user_name}, {count}, {date}
• कभी concatenate न करें: "Hello " + name जैसा स्ट्रिंग बिल्ड न करें
• यूनिट्स को स्ट्रिंग के अंदर रखें जब वे भाषा-निर्भर हों: {count} items न कि {count} + " items"
• अनुमत फ़ॉर्मेट पर परिभाषा दें: ISO तारीखें, करेंसी, या प्लेटफ़ॉर्म-विशिष्ट डेट फ़ॉर्मैट
• जटिल स्ट्रिंग्स के लिए छोटा नोट जोड़ें (उदाहरण: क्या {count} शून्य हो सकता है?)

बहुवचन और व्याकरण नियम जो रीवर्क बचाते हैं

बहुवचन वह जगह है जहाँ वर्कफ़्लो आमतौर पर पहले टूटता है। कई टीमें मानती हैं कि हर भाषा में सिर्फ "एक" और "कई" होते हैं, फिर पता चलता है कि UI गलत सुनता है या अंतिम समय पर फिक्स चाहिए।

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

एक मानक चुनें और उसे हर जगह लागू रखें (वेब, iOS, Android, बैकएंड-रेंडर्ड टेक्स्ट)। एक व्यावहारिक अप्रोच है कि अलग-अलग फॉर्म की कीज़ बनाने के बजाय एक की में प्लुरल फॉर्म्स स्टोर करें। CLDR केटेगरीज पर आधारित सेट चुनें ताकि वह वास्तविक भाषा नियमों से मेल खाए।

एक नियम जो रीवर्क रोकता है: UI वाक्यों को टुकड़ों से कभी न बनाएं जैसे "You have " + count + " messages"। शब्द क्रम बदल सकता है, और कुछ भाषाओं में संख्या के आधार पर अलग अंत या केस चाहिए।

एक व्यावहारिक की पैटर्न

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

• एक अवधारणा प्रति की उपयोग करें (उदाहरण: inbox.message_count)
• CLDR फॉर्म्स का समर्थन करें (zero, one, two, few, many, other)
• हमेशा प्लेसहोल्डर का उपयोग करें (उदाहरण: {count}) पूरे वाक्य के अंदर
• जब अर्थ अस्पष्ट हो तो अनुवादक नोट जोड़ें (क्या यह “messages” है या “unread messages”?)

जेंडर और व्याकरणिक केस

कभी-कभी बहुवचन नियम पर्याप्त नहीं होते। अगर आपकी UI किसी व्यक्ति से संबोधित करती है ("Welcome, Alex") या भूमिका बताती है ("assigned to him/her"), तो कुछ भाषाओं में जेंडर के आधार पर अलग शब्द चाहिए। अन्य भाषाएँ certain prepositions के बाद शब्दों के endings बदल देती हैं (व्याकरणिक केस)।

ऐसी स्थिति में, वास्तविक व्याकरणिक अलगियों के लिए अलग स्ट्रिंग्स बनाएं, सिर्फ स्टाइल के लिए नहीं। लक्ष्य कम कीज़ रखना है, पर QA के समय आश्चर्य भी कम करने हैं जब “सही” अनुवाद भी संदर्भ में गलत पढ़े।

प्लेटफ़ॉर्म्स पर फॉर्मैटिंग और लेआउट सीमाएँ

एक अनुवाद सही हो सकता है और फिर भी UI को तोड़ सकता है। वेब और नेटिव ऐप्स टेक्स्ट को अलग ढंग से रेंडर करते हैं, इसलिए आपके वर्कफ़्लो में फॉर्मैटिंग नियम और लेआउट चेक्स होने चाहिए, सिर्फ अनुवादित स्ट्रिंग्स नहीं।

संख्याएँ, पैसे और तारीखें कैसे दिखेंगी यह स्टैंडर्डाइज़ करें। इन्हें "$" + amount जैसा जोड़ कर न बनाएं या किसी लेबल में डेट फ़ॉर्मैट हार्डकोड न करें। लोकैल-अवेयर फ़ॉर्मैटर उपयोग करें ताकि विभाजक और क्रम अपेक्षाओं से मेल खाएँ (1,000.50 बनाम 1 000,50; day-month-year बनाम month-day-year)। टाइम ज़ोन सामान्य जाल है: टाइमस्टैम्प UTC में स्टोर करें, उपयोगकर्ता के लोकल ज़ोन में फॉर्मैट करें, और स्पष्ट करें जब कोई समय किसी विशिष्ट ज़ोन में हो।

टेक्स्ट डायरेक्शन भी एक चुप्पा ब्रेकर है। यदि आप right-to-left भाषाएँ सपोर्ट करते हैं, तो मिरर किए गए लेआउट और पंक्चुएशन की योजना बनाएं जो "सुझाते" आइकन (एरो, बैक बटन, प्रोग्रेस स्टेप्स) को फ़्लिप कर दें। एक त्वरित RTL पास रिव्यू का हिस्सा बनाएं, भले ही आप अभी पूरी तरह RTL सपोर्ट न कर रहे हों।

मोबाइल पर फ़ॉन्ट और स्पेसिंग वेब से अधिक बदल सकते हैं। वेब पर फिट होने वाला स्ट्रिंग SwiftUI या Kotlin में अजीब तरह से रैप कर सकता है। एक सुरक्षित न्यूनतम फ़ॉन्ट साइज़ तय करें, जहाँ उपयुक्त हो लेबल्स को रैप करने दें, और ऐसे fallback फ़ॉन्ट निर्धारित करें जो आपके डिफ़ॉल्ट फ़ॉन्ट के कवरेज में न हों।

एक्सेसिबिलिटी के लिए भी लोकलाइज़्ड चेक्स चाहिए। स्क्रीन रीडर संख्याएँ, संक्षेप, और मिक्स्ड-भाषा टेक्स्ट आश्चर्यजनक तरीकों से पढ़ सकता है।

लेआउट गार्डरेइल्स जो अधिकांश समस्याएँ रोकते हैं:

• टेक्स्ट विस्तार के लिए डिज़ाइन करें (30–50% लंबा) और फिक्स्ड-विथ बटन से बचें।
• डायनैमिक वैल्यूज़ (काउंट, प्राइस, तारीखें) अलग फॉर्मैटेड टोकन रखें।
• कस्टम पैटर्न के बजाय प्लेटफ़ॉर्म-नेटिव डेट और नंबर फ़ॉर्मैटर उपयोग करें।
• रिलीज़ से पहले एक RTL लोकल और एक “लॉन्ग टेक्स्ट” लोकल टेस्ट करें।
• मुख्य फ्लोज़ (लॉगिन, चेकआउट, सेटिंग्स) पर स्क्रीन-रीडर चेक्स चलाएँ।

उदाहरण: "Total: $1,234.50" लेबल को "1 234,50 €" में बदलना पड़ सकता है, प्रतीक मूल्य के बाद हो, अलग स्पेसिंग हो, और स्क्रीन रीडर के लिए "Total" और राशि के बीच एक उपयुक्त विराम चाहिए।

नई स्क्रीन से रिलीज़ तक स्टेप-बाय-स्टेप वर्कफ़्लो

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

प्रत्येक लेबल, बटन और संदेश को डिज़ाइन करते समय एक ट्रांसलेशन की जोड़ें। बेस भाषा में डिफ़ॉल्ट टेक्स्ट लिखें, और जल्दी संदर्भ जोड़ें जैसे कहाँ दिखाई देता है और क्रिया क्या करती है। checkout.pay_button जैसी की तब ही उपयोगी है जब अनुवादक को पता हो कि यह क्रिया वेरब है ("Pay") या लेबल ("Payment")।

UI को प्लेसहोल्डर्स और बेस भाषा फॉलबैक के साथ इम्प्लीमेंट करें। वेरिएबल स्पष्ट रखें (जैसे {name} या {count}) और वाक्यों को जोड़े हुए न बनाएं। यह भाषाओं में व्याकरण तोड़ने का सबसे तेज़ तरीका है।

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

अनुवाद वापस आने के बाद, उन्हें जल्दी मर्ज करें और वेब और नेटिव दोनों वर्ज़न बनाएं। उच्च-जोखिम स्क्रीनों पर त्वरित UI चेक करें: लॉगिन, ऑनबोर्डिंग, चेकआउट, और सेटिंग्स। कटा हुआ टेक्स्ट, ओवरलैपिंग एलिमेंट्स, गायब कीज़, और गलत प्लुरल रूप ढूँढें।

आखिरकार, रिलीज़ करें और मॉनिटर करें। गायब कीज़, फॉलबैक-टू-डिफ़ॉल्ट ईवेंट्स, और जिन स्क्रीन पर टेक्स्ट बार-बार ओवरफ़्लो होता है उन्हें ट्रैक करें।

अनुवादकों को सटीक बनने के लिए क्या चाहिए

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

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

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

"अनुवाद न करें" हिस्सों को स्पष्ट रूप से चिन्हित करें। प्रोडक्ट नाम, प्लान नाम, कूपन कोड, API फील्ड और {name} जैसे प्लेसहोल्डर अनुवादित नहीं होने चाहिए। बिना गाइडेंस के अनुवादक इन्हें लोकलाइज़ कर सकते हैं और आपका ऐप अर्थहीन हो सकता है।

प्रत्येक स्ट्रिंग के लिए एक व्यावहारिक पैकेज:

• स्क्रीनशॉट या स्क्रिन का नाम (उदाहरण: “Checkout - Payment method”)
• प्रकार और उद्देश्य (भुगतान की पुष्टि करने वाला बटन)
• टोन नोट (शांत, आश्वस्त)
• सीमाएँ (अधिकतम 18 कैरेक्टर, एक पंक्ति)
• संरक्षित टोकन (प्रोडक्ट नाम, इंटीग्रेशन, {amount})

लीगल टेक्स्ट और सपोर्ट कंटेंट को अलग स्ट्रीम के रूप में रखें। लीगल कॉपी अक्सर अप्रूवल और धीमे अपडेट की मांग करती है, इसलिए इसे उत्पाद UI स्ट्रिंग्स से अलग रखें और संस्करण नियंत्रित रखें। सपोर्ट आर्टिकल और हेल्प स्निपेट आम तौर पर लंबे अनुवाद मांगते हैं और वे अलग सिस्टम या फाइल सेट में रह सकते हैं।

उदाहरण: मोबाइल पर एक “Continue” बटन के लिए वेब की तुलना में सख्त लिमिट हो सकती है। अगर अनुवादक इसे जानता है, तो वे उन भाषाओं में संक्षिप्त क्रिया चुन सकते हैं जहाँ टेक्स्ट फैलता है बजाय बाद में UI री-डिज़ाइन करने के।

QA और रिव्यू लूप जो ब्रोकन UI को रोकता है

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

डेवलपमेंट बिल्ड में pseudo-localization से शुरू करें। असली स्ट्रिंग्स की जगह लंबे, एक्सेंटेड वर्ज़न (जैसे "[!!! Šéttïñĝš !!!]") डालें और लंबाई 30–50% बढ़ाएँ। इससे जल्दी truncation, overlap, और हार्ड-कोडेड स्ट्रिंग्स दोनों वेब और नेटिव पर दिखेंगी।

हर बिल्ड पर ऑटोमेटेड चेक जोड़ें। वे उन उबाऊ गलतियों को पकड़ते हैं जो इंसान सैकड़ों लाइनों की समीक्षा में मिस कर देते हैं:

• किसी भी लोकल में गायब कीज़ (fallbacks बाद में समस्याएँ छुपाते हैं)
• अनयूज़्ड कीज़ (यह संकेत है कि आप drift कर रहे हैं और डेड टेक्स्ट शिप हो रहा है)
• प्लेसहोल्डर मिसमैच ("Hello, {name}" vs "Hello, {username}")
• किसी लोकल के लिए अमान्य प्लुरल फॉर्म्स (zero, one, few, many)
• मोबाइल स्ट्रिंग्स में कच्चे HTML जैसे फॉरबिड्ड पैटर्न

फिर एक स्पष्ट मैन्युअल साइन-ऑफ लूप रखें। उत्पाद प्रमुख स्क्रीन के अर्थ और टोन की पुष्टि करे, जबकि QA लेआउट और इंटरैक्शन जाँच करे।

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

जब मुद्दे रिपोर्ट करें तो फिक्स्स को आसान बनाएं: लोकल, डिवाइस और OS वर्ज़न (या ब्राउज़र और विड्थ), अपेक्षित टेक्स्ट, वास्तविक टेक्स्ट, और कटे हुए हिस्से का स्क्रीनशॉट शामिल करें। अगर यह प्लुरलाइज़ेशन या प्लेसहोल्डर्स से संबंधित है, तो सटीक की और रेंडर्ड स्ट्रिंग पेस्ट करें।

सामान्य गलतियाँ और उन्हें कैसे टालें

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

एक सामान्य जाल है कीज़ का नाम बदलना जब आप केवल वर्डिंग बदलना चाहते हैं। कीज़ स्थिर IDs होनी चाहिए, टेक्स्ट नहीं। अगर आप checkout.button.pay को checkout.button.pay_now में बदल देते हैं, तो हर पुराना अनुवाद "गायब" हो जाएगा और आप इतिहास खो देंगे। की रखें, डिफ़ॉल्ट-भाषा स्ट्रिंग अपडेट करें, और अगर अर्थ बदला है तो संदर्भ जोड़ें।

एक और समस्या एक प्लेटफ़ॉर्म पर स्ट्रिंग्स को हार्डकोड करना है। वेब टीम कीज़ का उपयोग करती है, पर मोबाइल टीम जल्दी फिक्स के लिए literal टेक्स्ट डाल देती है। एक महीने बाद iOS पर यूज़र्स अंग्रेज़ी-ओनली अलर्ट देखते हैं। "यूज़र-फेसिंग स्ट्रिंग्स में कोई हार्डकोड न हो" यह नियम वेब और नेटिव दोनों के लिए साझा रखें।

प्लेसहोल्डर सूक्ष्म गलतियाँ तब करते हैं जब आप शब्द क्रम मान लेते हैं। अंग्रेज़ी में "{count} items" काम कर सकता है, पर अन्य भाषाओं में अलग क्रम या अतिरिक्त शब्द चाहिए। नामित प्लेसहोल्डर्स (नंबरिंग नहीं) उपयोग करें और प्लेटफ़ॉर्म्स में उन्‍हें सुसंगत रखें।

जल्दी पकड़ी जाने योग्य गलतियाँ:

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

केवल एक "लॉन्ग लैंग्वेज" टेस्ट करना पर्याप्त नहीं है। जर्मन अक्सर UI फैलाता है, जबकि चीनी स्पेसिंग मुद्दे छुपा सकता है। त्वरित पास दोनों पर करें, और साथ ही 0, 1, और 2 जैसे प्लुरल एज केस भी टेस्ट करें।

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

त्वरित चेकलिस्ट और व्यावहारिक अगले कदम

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

UI परिवर्तन मर्ज करने से पहले सामान्य "उह-oh" मुद्दों के लिए तेज़ पास करें:

• नई कीज़ आपके नामकरण नियमों का पालन करती हैं और सही namespace में रहती हैं (स्क्रीन या फीचर)
• प्लेसहोल्डर्स सभी भाषाओं में ठीक मेल खाते हैं (एक ही वेरिएबल, एक ही अर्थ)
• प्लुरल फॉर्म्स आपके समर्थित भाषाओं के लिए पूरे हैं (सिर्फ अंग्रेज़ी सिंगुलर/प्लुरल नहीं)
• UI में कोई हार्डकोडेड टेक्स्ट नहीं बचा है (एरर स्टेट्स और खाली स्टेट्स सहित)
• नई या बदली टेक्स्ट का बेसिक संदर्भ कैप्चर किया गया है (स्क्रीनशॉट या स्पष्ट नोट)

शिप करने से पहले एक छोटा रिलीज़ QA चलाएँ जो उन जगहों पर फोकस करे जहाँ लोकलाइज़ेशन पहले टूटता है। समय-सीमा रखें पर सुसंगत रहें: हर प्लेटफ़ॉर्म पर टॉप यूज़र फ्लोज़, एक RTL spot check, लंबी टेक्स्ट स्क्रीन (सेटिंग्स, लीगल, ऑनबोर्डिंग, टेबल, संकरे बटन), और कुछ लोकल्स में तारीख/नंबर/करेंसी फ़ॉर्मैटिंग।

अपनी टीम के अनुकूल कैडेंस सेट करें। कई टीमें साप्ताहिक रूप से अनुवाद अपडेट करती हैं, फिर रिलीज़ से 1–2 दिन पहले स्ट्रिंग्स फ्रीज़ कर देती हैं। लक्ष्य यह है कि अंतिम समय की कॉपी एडिट्स और फाइनल QA एक साथ न हों।

अगले कदम जो जल्दी लाभ देंगे: अपनी कन्वेंशंस (की नामकरण, प्लेसहोल्डर, प्लुरल नियम, मालिकाना) लिखें, और फिर एक पायलट स्क्रीन end-to-end चलाएँ और टूटने के आधार पर समायोजित करें।

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