बहुभाषी सूचना टेम्पलेट जो सुसंगत रहें

बहुभाषी नोटिफिकेशन सिंक से क्यों हट जाते हैं

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

सबसे बड़ा कारण वह छोटा बदलाव है जो "सिर्फ एक संदेश के लिए" किया जाता है। कोई वाक्य अंग्रेज़ी में जोड़ देता है और दूसरी जगह उसे भूल जाता है। या वे {first_name} जैसे प्लेसहोल्डर को {name} से बदल देते हैं ताकि नया डेटा मॉडल मेल खाए, और केवल अंग्रेज़ी टेम्पलेट अपडेट होता है। परिणाम होता है गायब हुआ अभिवादन, टूटा हुआ वेरिएबल, या ऐसा टेक्स्ट जो फॉर्म लेटर जैसा लगता है।

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

असंगति आमतौर पर अनुमानित जगहों से शुरू होती है:

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

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

एक ठोस उदाहरण: आपकी अंग्रेज़ी भुगतान रसीद "Your card was charged {amount} on {date}" से बदल कर "We received your payment of {amount}." हो जाती है। अगर स्पैनिश वर्ज़न पुरानी लाइन रखता है और फ्रेंच वर्ज़न {date} खो देता है क्योंकि वह अब डेटा में मौजूद नहीं है, तो ग्राहक स्क्रीनशॉट्स की तुलना करेंगे और समझेंगे कि कुछ गड़बड़ है।

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

एक सरल मॉडल: एक इंटेंट, कई आउटपुट

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

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

एक इंटेंट कार्ड के साथ शुरू करें

टेम्पलेट्स छेड़ने से पहले एक छोटा, साधारण भाषा में स्पेक लिखें। बताएं कि किन चीज़ों को लोकलों के पार बदलना नहीं चाहिए (तथ्य, संख्याएँ, आवश्यक शब्द) और क्या अलग हो सकता है (टोन, वाक्य क्रम, सांस्कृतिक मानदंड)।

एक व्यावहारिक इंटेंट कार्ड में शामिल होने चाहिए:

• लक्ष्य: उपयोगकर्ता को क्या समझना या करना चाहिए
• आवश्यक तथ्य: राशियाँ, तिथियाँ, उत्पाद नाम, समय-सीमाएँ
• अनुमति प्राप्त विविधता: अभिवादन स्टाइल, विराम चिन्ह, औपचारिकता स्तर
• कॉल टू एक्शन: एक स्पष्ट अगला कदम

अब आपका ईमेल, SMS और चैट वर्ज़न उसी इंटेंट के आउटपुट बन जाते हैं, न कि अलग कॉपी प्रोजेक्ट।

एक स्रोत-सत्यता वेरिएबल सेट

फैसला एक बार करें कि कौन से वेरिएबल मौजूद हैं और उनका क्या अर्थ है, फिर उन्हें हर जगह पुन: उपयोग करें। अगर आपके पास {{first_name}}, {{invoice_total}}, और {{due_date}} हैं, तो ये प्लेसहोल्डर भाषाओं और चैनलों में समान होने चाहिए, एक ही डेटा टाइप और फ़ॉर्मैटिंग नियमों के साथ।

यदि आप AppMaster जैसे टूल में नोटिफिकेशन बना रहे हैं, तो वर्कफ़्लो (उदाहरण के लिए, एक Business Process के भीतर) में वेरिएबल्स को एक बार परिभाषित करना और हर टेम्पलेट में फ़ीड करना मदद करता है। इससे ईमेल में {{amount}} और SMS में {{total}} जैसे "लगभग समान" प्लेसहोल्डर से बचा जा सकता है।

चैनल ड्रिफ्ट रोकने के लिए, कॉपी बदलावों के लिए एक सरल अनुमोदन पथ सेट करें:

• कॉपी ओनर इंटेंट कार्ड में परिवर्तन प्रस्तावित करे
• लोकलाइज़र प्रभावित लोकल अपडेट करें
• चैनल ओनर पुष्टि करें कि प्रतिबंध अभी भी उपयुक्त हैं
• एक रिव्यूर साइन-ऑफ करे और रिलीज़ शेड्यूल करे

यह इंटेंट को स्थिर रखता है जबकि हर आउटपुट छोटा, स्पष्ट और चैनल-अनुकूल बना रहता है।

वेरिएबल और प्लेसहोल्डर्स को बिना आश्चर्य के प्रबंधित करना

टेम्पलेट्स सबसे अधिक तब टूटते हैं जब वेरिएबल्स के किनारे खुलते हैं। एक भाषा में ठीक पढ़ता है, दूसरी में नाम गायब हो जाता है, तारीख अजीब दिखती है, या विराम से पहले अतिरिक्त स्पेस आ जाता है। समाधान "और प्रूफ़रीडिंग" नहीं है। यह वेरिएबल्स को एक छोटे प्रोडक्ट की तरह नियमों के साथ ट्रीट करना है।

चैनल और भाषाओं में साझा वेरिएबल कैटलॉग से शुरू करें। हर वेरिएबल को एक अर्थ, और अनुवादकों के लिए उदाहरण चाहिए। नाम उबाऊ और स्थिर रखें भले ही उसके चारों ओर की वर्डिंग बदल जाए। अगर आप बार-बार वेरिएबल का नाम बदलते हैं, तो पुराने टेम्पलेट चुपचाप खराब हो जाते हैं।

एक व्यावहारिक कैटलॉग एंट्री में शामिल होना चाहिए:

• वेरिएबल नाम (उदाहरण के लिए, {order_id})
• साधारण शब्दों में अर्थ
• एक अच्छा उदाहरण मान और एक एज केस
• यह कहाँ से आता है (सिस्टम, उपयोगकर्ता इनपुट, डेटाबेस)
• क्या यह आवश्यक है या वैकल्पिक

फ़ॉर्मैटिंग नियम अनुवाद जितने ही मायने रखते हैं। तिथियाँ, मुद्रा और संख्याएँ सुसंगत रूप से फॉर्मैट होनी चाहिए, या कम से कम लोकल के अनुसार। पहले तय करें कि क्या आप टेम्पलेट में पहले से फॉर्मैट की गई स्ट्रिंग्स पास करेंगे (SMS और चैट के लिए सुरक्षित), या टेम्पलेट सिस्टम के अंदर फॉर्मैट करेंगे (ज़्यादा लचीला, पर गलत होने में आसान)।

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

उदाहरण के लिए, अगर {first_name} गायब है, तो "Hi {first_name}, your receipt is ready" बनना चाहिए "Hi, your receipt is ready" (नाम और कॉमा हटा दें)। अगर आप टेक्स्ट को ऑटोमेटिकली नहीं हटा सकते, तो ग्रीटिंग ऐसी लिखें जो नाम पर निर्भर न हो।

टीम नियमों का एक साधारण सेट बहुत बढ़िया फर्क डालता है:

• ईमेल, SMS, और चैट के लिए एक ही वेरिएबल सेट का उपयोग करें
• वेरिएबल्स को आवश्यक या वैकल्पिक के रूप में मार्क करें और इसे परीक्षणों में लागू करें
• तारीख, संख्या, और मुद्रा के लिए लोकल-आवेयर फॉर्मैटर का उपयोग करें
• सत्यापित करें कि हर टेम्पलेट केवल अनुमोदित कैटलॉग का ही उपयोग करे

फॉलबैक जो टूटा हुआ नहीं लगता

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

पहले एक फॉलबैक ऑर्डर चुनें और उसे हर जगह उपयोग करें। एक सामान्य नियम है: exact locale (fr-CA) → base language (fr) → default language (अक्सर en)। कुंजी है सुसंगति। अगर ईमेल एक ऑर्डर उपयोग करता है और SMS दूसरा, तो लोग नोटिस कर लेंगे।

फॉलबैक टेक्स्ट सुरक्षित और तटस्थ होना चाहिए। डिफ़ॉल्ट कॉपी में चुटकियाँ, बोलचाल या संस्कृति-विशेष संदर्भ से बचें। वाक्य छोटे रखें, मुहावरों से बचें, और सुनिश्चित करें कि तारीखें, समय और मुद्रा फॉलबैक होने पर भी पठनीय रहें।

कुछ संदेश कभी फॉल बैक नहीं होने चाहिए क्योंकि जोखिम बहुत अधिक है। इनके लिए भेजना ब्लॉक करना या एक छोटा स्वीकृत "सपोर्ट से संपर्क करें" संदेश भेजना बेहतर है।

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

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

संवेदनशील सामग्री स्टोर किए बिना कार्रवाई के लिए पर्याप्त विवरण लॉग करें:

• संदेश इंटेंट (जैसे "order_shipped")
• चैनल (email, SMS, chat)
• अनुरोधित लोकल और वास्तविक रूप से उपयोग किया गया लोकल
• टेम्पलेट वर्ज़न या कॉमिट टैग
• टाइमस्टैम्प और भेजने का परिणाम (sent, failed, blocked)

उदाहरण: आप नया "delivery delayed" नोटिफिकेशन भेजते हैं। एक उपयोगकर्ता का लोकल es-MX है, लेकिन सिर्फ es-ES मौजूद है। locale → language → default नियम के साथ, उन्हें अंग्रेज़ी की जगह स्पैनिश मिलता है, और आपके लॉग दिखाते हैं कि es-MX ने es पर फॉल बैक किया। यह स्पष्ट टास्क देता है: केवल तभी es-MX जोड़ें जब शब्दावली क्षेत्रीय ट्वीक मांगती हो, न कि इसलिए कि यह पूरी तरह से गायब था।

प्रति-चैनल सीमाएँ: ईमेल, SMS, और चैट अलग हैं

एक टेम्पलेट जो ईमेल में अच्छा पढ़ता है, SMS में असफल हो सकता है, और चैट संदेश इनबॉक्स में पेस्ट होने पर बिखरा हुआ दिख सकता है। एक साझा इंटेंट और वेरिएबल कॉन्ट्रैक्ट रखें, पर हर चैनल को उसकी अपनी फ़ॉर्मैट और सीमाओं के साथ ट्रीट करें।

ईमेल: अधिक जगह, अधिक हिस्से

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

HTML लेआउट में मदद कर सकता है, पर एक सादा टेक्स्ट वर्ज़न रखें जो फिर भी समझ में आए। कुछ भाषाओं को अतिरिक्त लाइन ब्रेक्स या अलग विराम आवश्यकता हो सकती है, जो HTML में ठीक दिखे पर सादा टेक्स्ट में भ्रमित कर दे। एक साधारण टेस्ट यह है कि सादा टेक्स्ट वर्ज़न को ज़ोर से पढ़ें: अगर वह फॉर्म लेटर जैसा लगता है तो यह तैयार नहीं है।

SMS: कसी हुई सीमाएँ, कम फीचर्स

SMS माफ़ नहीं करता। एन्कोडिंग के अनुसार कैरेक्टर लिमिट अलग होती है, और गैर-लैटिन लिपियाँ एक संदेश में फिट होने वाले कैरेक्टर्स को घटा सकती हैं। कोर पॉइंट पहले रखें: किसके लिए है, क्या हुआ, और अगला कदम क्या है।

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

चैट ऐप्स: फ़ॉर्मैटिंग, बटन, लाइन ब्रेक

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

लंबी नियम-सूची की बजाय हर चैनल के लिए एक छोटा "न भेजें" सेट रखें और हर लोकल को उसके खिलाफ चेक करें। उदाहरण: कच्चे प्लेसहोल्डर, दुहराए हुए अभिवादन, या एक सब्जेक्ट लाइन जो कटने पर बकवास बन जाए।

एक व्यावहारिक आदत यह है कि पहले SMS वर्ज़न लिखें, फिर चैट के लिए विस्तार करें, और केवल फिर ईमेल विवरण जैसे सब्जेक्ट और फ़ॉर्मैट जोड़ें। यह स्पष्टता को मजबूरी में लाता है पहले कि आप एक्स्ट्रा जोड़ें।

सुसंगत टेम्पलेट बनाने का स्टेप-बाय-स्टेप वर्कफ़्लो

सुसंगति एक दोहराने योग्य ऑर्डर से आती है। जब हर कोई एक ही कदमों का पालन करता है, तो टेम्पलेट ड्रिफ्ट करना बंद कर देते हैं और रखरखाव आसान हो जाता है।

1) एक स्पष्ट इंटेंट से शुरू करें

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

2) जल्दी वेरिएबल्स और नियम लॉक करें

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

3) एक ही प्लेसहोल्डर सेट का उपयोग कर प्रत्येक लोकल के लिए अनुवाद करें

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

4) अर्थ बदले बिना हर चैनल के लिए ढालें

लोकल टेम्पलेट से चैनल-विशेष वर्ज़न बनाएं। ईमेल में संदर्भ अधिक हो सकता है, SMS में संक्षिप्तता चाहिए, और चैट अक्सर छोटे लाइनों से लाभ उठाता है। वादा और अगला कदम वही रहने चाहिए।

5) हर लोकल में टेस्ट डेटा के साथ प्रीव्यू करें

हर लोकल और चैनल में वास्तविक सैंपल डेटा दौड़ाकर प्रीव्यू करें। यहीं आप अटपटी लाइन ब्रेक्स, गायब वेरिएबल्स, और कटने की समस्याएँ पकड़ते हैं।

एक सरल बिल्ड लूप:

1. एक स्पष्ट अगला कदम के साथ बेस संदेश ड्राफ्ट करें।
2. आवश्यक और वैकल्पिक वेरिएबल्स और वैलिडेशन define करें (टाइप, लंबाई, अनुमत मान)।
3. एक ही प्लेसहोल्डर्स का उपयोग करके हर लोकल में अनुवाद करें।
4. अर्थ और टोन बनाए रखते हुए प्रति-चैनल वर्ज़न बनाएं।
5. रिलीज़ से पहले टेस्ट डेटा से प्रीव्यू करें और मुद्दे ठीक करें।

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

टेस्टिंग के लिए, एक छोटे सेट के स्ट्रेस सैंपल्स (लंबा नाम, गायब अंतिम नाम, बड़ी राशि, अलग टाइमज़ोन) का उपयोग करें ताकि टेम्पलेट वास्तविक उपयोगकर्ताओं के लिए काम करें, केवल परफेक्ट डेटा के लिए नहीं।

लोकलाइज़ेशन विवरण जो अक्सर बग पैदा करते हैं

भले ही अनुवाद सही हो, छोटे लोकलाइज़ेशन विवरण भी टेम्पलेट्स को तब तोड़ सकते हैं जब वास्तविक डेटा प्लेसहोल्डर्स में आता है।

संख्याओं के आस-पास बहुवचन और व्याकरण

Plural नियम सिर्फ एकवचन बनाम बहुवचन नहीं हैं। कुछ भाषाओं में कई बहुवचन रूप होते हैं, और क्रिया या विशेषण भी बदलते हैं। "You have {{count}} new tickets" जैसे संदेश 0, 1, 2, या 11 पर सूक्ष्म तरीकों से गलत हो सकते हैं।

जब प्लुरल नियम मायने रखते हैं, तो एक वाक्य में संख्या डालने की बजाय संरचित वेरिएंट स्टोर करें। संख्या फॉर्मैटिंग लोकल के अनुसार सुसंगत रखें (1,000 बनाम 1 000), और बिज़नेस लॉजिक में स्ट्रिंग जोड़कर व्याकरण बनाने से बचें।

नाम, क्रम, और सम्मान-सूचक शब्द

नाम जटिल हैं: कुछ संस्कृतियाँ परिवार नाम पहले रखती हैं, कुछ लोगों का एक ही नाम होता है, और सम्मान-सूचक शब्द बदलते हैं। अगर आपका टेम्पलेट कहता है "Hi {{first_name}}", तो यह तब फेल कर सकता है जब आपके पास केवल एक पूरा नाम हो, या नाम विभाजन गलत हो।

एक डिस्प्ले नाम फ़ील्ड पसंद करें जिसे आप कंट्रोल करते हैं, और एक फॉलबैक चेन परिभाषित करें जो टोन को बनाए रखे:

• डिस्प्ले नाम
• पहले नाम
• पूरा नाम
• एक तटस्थ अभिवादन (जैसे "Hello")

टाइमज़ोन और तारीख फ़ॉर्मैट

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

लोकल-आवेयर फॉर्मैट्स का उपयोग करें और रिसिपिएंट के टाइमज़ोन में कन्वर्ट करें। एक अपॉइंटमेंट रिमाइंडर एक लोकल के लिए "4 Mar 2026, 09:30" और किसी अन्य के लिए "Mar 4, 2026, 9:30 AM" दिखा सकता है, एक ही स्टोर्ड UTC टाइमस्टैम्प से।

दाएँ-से-बाएँ भाषाएँ और विराम चिन्ह

आरटीएल भाषाएँ जटिल मामले लाती हैं: विराम चिन्ह, कोष्ठक, और मिश्रित सामग्री जैसे ऑर्डर आईडी गलत दृश्य क्रम में आ सकती हैं। यहां तक कि एक सरल स्ट्रिंग जैसे "Order #{{order_id}}" उलझी दिख सकती है।

RTL टेम्पलेट्स को वास्तविक डेटा (नंबर्स, ईमेल, प्रोडक्ट कोड) के साथ टेस्ट करें। शक होने पर वेरिएबल ब्लॉकों को छोटा रखें और उन्हें ऐसे विराम चिन्हों से घेरने से बचें जो उलट सकते हैं।

सामान्य गलतियाँ और जाल

सबसे तेज़ तरीका सुसंगति तोड़ने का यह है कि हर भाषा को अलग संदेश मानना। आप शिप कर सकते हैं, पर छोटे अंतर जमा हो जाते हैं और उपयोगकर्ता नोटिस करते हैं।

ऐसी गलतियाँ जो ड्रिफ्ट करती हैं:

• भाषा के अनुसार वेरिएबल्स का नाम बदलना ({first_name} अंग्रेज़ी में पर {name} स्पैनिश में)। अनुवादक उसके चारों ओर काम करते हैं, फिर एक लोकल ब्लैंक्स या कच्चे प्लेसहोल्डर दिखाता है।
• अनुवादित टेक्स्ट में हार्डकोडेड मान (मूल्य या तारीख को प्लेन टेक्स्ट में लिखना)। जब वह मान बदलता है, तो एक भाषा गलत हो जाएगी।
• हर जगह एक ही SMS वर्ज़न का उपयोग करना बिना लंबाई जाँचे। अंग्रेज़ी में फिट होने वाली कॉपी जर्मन में दो संदेश बन सकती है, या कैरियर उसे सबसे बुरे स्थान पर विभाजित कर सकते हैं।
• लोकलों में टोन की मिक्सिंग। अगर अंग्रेज़ी अनौपचारिक और दोस्ताना है पर फ्रेंच औपचारिक है, तो ब्रांड वॉइस यादृच्छिक लगती है।
• मिसिंग डेटा के लिए परीक्षण छोड़ना। असली सिस्टम हमेशा एज केस रखता है: कोई अंतिम नाम नहीं, कोई डिलीवरी विंडो नहीं, अज्ञात स्थान।

एक ठोस उदाहरण: एक पासवर्ड रीसेट SMS आपके मुख्य भाषा में ठीक दिख सकता है, पर किसी अन्य लोकल में लिंक प्लेसहोल्डर अलग है, इसलिए उपयोगकर्ता देखता है "Reset here: {url}." यह एक सपोर्ट टिकट है जिसे आप टाल सकते हैं।

अधिकांश समस्याएँ रोकने वाली छोटी आदतें:

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

भेजने से पहले त्वरित चेकलिस्ट

वास्तविक ग्राहकों को भेजने से पहले, उसी सावधानी के साथ आख़िरी जाँच करें जैसे आप पासवर्ड रीसेट ईमेल की करते हैं।

डेटा और प्लेसहोल्डर्स से शुरू करें। अगर संदेश कहता है "Hi {first_name}", तो सुनिश्चित करें कि हर ट्रिगर पाथ के लिए वह वैल्यू मौजूद है। पुष्टि करें कि फ़ॉर्मैटिंग नियम लोकल से मेल खाते हैं (तिथियाँ, समय, मुद्रा, और नाम क्रम)।

प्री-फ़्लाइट चेकलिस्ट:

• सत्यापित करें कि हर प्लेसहोल्डर मौजूद है, सभी लोकलों में एक जैसा लिखा गया है, और अपेक्षित फ़ॉर्मैट में है (उदा. "12 Jan" बनाम "12/01").
• जानबूझकर एक फ़ील्ड हटाकर फॉलबैक व्यवहार टेस्ट करें (कोई पहला नाम नहीं, कोई डिलीवरी विंडो नहीं, कोई कंपनी नाम नहीं) और पुष्टि करें कि संदेश अभी भी स्वाभाविक पढ़े।
• वास्तविक उपकरणों और प्रीव्यू में लंबाई जांचें, खासकर SMS और चैट जहाँ टेक्स्ट कट या विभाजित होता है।
• शीर्षक और सब्जेक्ट लाइनों को ट्रंक होने के लिए जाँचें, और पुष्टि करें कि कटने पर भी वे अर्थपूर्ण रहें।
• कम से कम एक पूर्ण एंड-टू-एंड टेस्ट चलाएँ प्रति लोकल, ट्रिगर से लेकर अंतिम डिलीवरी तक।

एक त्वरित चैनल-रियलिज़्म पास करें। एक लाइन जो ईमेल में दोस्ताना लगे वह SMS में दबावपूर्ण लग सकती है, और चैट संदेश को स्पष्ट पहले वाक्य की ज़रूरत हो सकती है क्योंकि उपयोगकर्ता केवल प्रीव्यू देखते हैं।

उदाहरण: आप अंग्रेज़ी और स्पैनिश में ऑर्डर अपडेट भेजते हैं। स्पैनिश में ग्राहक का नाम गायब है, इसलिए "Hola , tu pedido..." टूटता हुआ दिखता है। इसका हल केवल तकनीकी फॉलबैक "Hola," नहीं है। यह मानव-केंद्रित फॉलबैक है जैसे "Hola, gracias por tu pedido" जो संदर्भ में काम करे।

उदाहरण परिदृश्य और व्यावहारिक अगले कदम

एक साफ़ तरीका सुसंगति जांचने का यह है कि एक इंटेंट चुनें और उसे तीन चैनलों के माध्यम से भेजें। दो हाई-स्टेक संदेश हैं: पासवर्ड रीसेट और सुरक्षा अलर्ट।

दोनों के लिए, एक ही छोटे वेरिएबल सेट को एक बार परिभाषित करें और फिर हर जगह पुन: उपयोग करें: first_name, reset_code, support_email, device_name, city, time, manage_link.

यहाँ दिखाया गया है कि वही वेरिएबल्स हर चैनल में कैसे दिख सकते हैं जबकि वे अभी भी फिट होते हैं।

ईमेल (अधिक जगह, गर्म टोन):

"Hi {first_name}, we received a request to reset your password. Your code is {reset_code}. If you did not request this, secure your account here: {manage_link}."

SMS (संकुचित, बिना एक्स्ट्रा):

"Your reset code: {reset_code}. If this was not you, secure your account: {manage_link}"

चैट संदेश (तेज़, दोस्ताना):

"Password reset code: {reset_code}\nNeed help? Reply to this message or use {manage_link}."

फॉलबैक तब सबसे ज़रूरी होते हैं जब डेटा गायब हो। यदि first_name खाली है, तो "Hi ," न दिखाएँ। "Hi there," का उपयोग करें या अभिवादन हटा दें। यदि device_name अज्ञात है सुरक्षा अलर्ट में, तो "New sign-in from null." से बचें। इसके बजाय "New sign-in from a new device" का उपयोग करें और बाकी को विशिष्ट रखें: "Location: {city} at {time}."

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

व्यावहारिक अगले कदम:

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

यदि आप इन फ़्लोज़ को AppMaster (appmaster.io) में बना और ऑर्केस्ट्रेट कर रहे हैं, तो मुख्य लाभ यह है कि साझा डेटा मॉडल और वर्कफ़्लो लॉजिक को अपने टेम्पलेट्स के पास रखना, ताकि वेरिएबल्स सुसंगत रहें और आप एक ही इंटेंट से ईमेल, SMS, और चैट आउटपुट जेनरेट कर सकें।