5.5 अंतर्राष्ट्रीयकरण और स्थानीयकरण

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

आर्किटेक्चर को एक बार अंतर्राष्ट्रीयकृत करें; सामग्री को कई बार स्थानीयकृत करें।
उपयोगकर्ता-सामना करने वाले पाठ को कभी हार्ड-कोड न करें; सभी स्ट्रिंग को प्रबंधित संसाधनों में बाह्यीकृत करें।
हर जगह यूनिकोड (UTF-8) का उपयोग करें; मान लें कि पाठ किसी भी लिपि में हो सकता है।
अनुवादित टुकड़ों को कभी न जोड़ें; व्याकरण और शब्द क्रम भाषा के अनुसार अलग होते हैं।
पाठ विस्तार, दाएं-से-बाएं लिपियों, और जटिल बहुवचन और लिंग नियमों के लिए योजना बनाएं।
तारीखों, संख्याओं, मुद्राओं, और नामों को लोकेल के अनुसार प्रारूपित करें, कोड के अनुसार नहीं।
अनुवाद योग्य सामग्री को कोड से अलग करें ताकि अनुवादक कभी स्रोत को न छुएं।
स्थानीयकरण सांस्कृतिक है, केवल भाषाई नहीं: रंग, चित्रण, और उदाहरण मायने रखते हैं।

सिफारिशें

एक सुदृढ़ अंतर्राष्ट्रीयकरण आर्किटेक्चर बनाएं

सभी पाठ को शुरू से अंत तक (डेटाबेस, API, और UI) यूनिकोड (UTF-8) के रूप में संग्रहीत और संसाधित करें ताकि कोई भी लिपि निरूपण योग्य हो। हर उपयोगकर्ता-सामना करने वाली स्ट्रिंग को पहचानकर्ता द्वारा कुंजीबद्ध संसाधन फ़ाइलों या एक संदेश कैटलॉग में बाह्यीकृत करें, कभी कोड या मार्कअप में एम्बेडेड नहीं। एक लोकेल को भाषा और क्षेत्र (और ज़रूरत होने पर लिपि) के रूप में दर्शाएं ताकि आप, उदाहरण के लिए, देशों में एक भाषा के प्रकारों में अंतर कर सकें। तारीख, संख्या, और मुद्रा प्रारूपण को हाथ से बनाने के बजाय एक अच्छी तरह से परखी गई अंतर्राष्ट्रीयकरण लाइब्रेरी में प्रारूपण तर्क रखें। डेटा को तटस्थ, स्पष्ट रूपों (UTC टाइमस्टैम्प, ISO देश और मुद्रा कोड, आधार इकाइयां) में संग्रहीत करें और केवल प्रस्तुति परत पर प्रारूपित करें।

भाषा जटिलता को सही ढंग से संभालें

पाठ की लंबाई मान न लें; उदार जगह रखें क्योंकि अनुवाद आमतौर पर अंग्रेज़ी से कहीं ज़्यादा लंबे होते हैं, और ऐसे लेआउट डिज़ाइन करें जो काटने या ओवरलैप होने के बजाय फिर से प्रवाहित (reflow) हों। द्विदिशात्मक (दाएं-से-बाएं) लिपियों का समर्थन तार्किक (logical) लेआउट गुणों का उपयोग करके करें न कि भौतिक (physical) का, और जहां उपयुक्त हो वहां इंटरफ़ेस को मिरर करें। नैव एकवचन/बहुवचन तर्क के बजाय अपनी i18n लाइब्रेरी के माध्यम से लोकेल के बहुवचन नियमों का उपयोग करें (भाषाओं में एक से लेकर छह बहुवचन रूप तक होते हैं)। जहां भाषा की ज़रूरत हो वहां लिंग और व्याकरणिक सामंजस्य को संभालें। कभी वाक्यों को जोड़कर न बनाएं; पूर्ण, पैरामीटरीकृत संदेश टेम्पलेट का उपयोग करें ताकि अनुवादक शब्द क्रम को नियंत्रित करें।

एक स्थानीयकरण कार्यप्रवाह और अनुवाद प्रबंधन स्थापित करें

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

केवल शब्दों को नहीं, प्रारूपों, संस्कृति, और सामग्री को स्थानीयकृत करें

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

i18n को साझा इन्फ्रास्ट्रक्चर के रूप में शासित करें

एक साझा i18n लाइब्रेरी, स्ट्रिंग-बाह्यीकरण लिंट नियम, और एक मानक लोकेल-समाधान तंत्र प्रदान करें ताकि टीमें गलती से पाठ को हार्ड-कोड न कर सकें। स्थानीयकरण पाइपलाइन और शब्दावलियों का स्वामित्व स्थापित करें। CI में कई लोकेल में परीक्षण करें, जिसमें एक दाएं-से-बाएं लोकेल और एक लंबे-पाठ वाला स्यूडो-लोकेल शामिल हो, ताकि रिग्रेशन स्वचालित रूप से पकड़े जाएं।

ट्रेड-ऑफ: फायदे और नुकसान

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

महत्वपूर्ण ट्रेड-ऑफ यह है कि अंतर्राष्ट्रीयकरण में कब निवेश करें। हार्ड-कोडेड, जोड़ी गई, लैटिन-मानने वाले कोड से भरे एक उत्पाद में i18n को रेट्रोफिट करना तकनीकी ऋण के अधिक महंगे रूपों में से एक है जिसे चुकाना पड़ता है। किसी भी ऐसे संगठन के लिए जिसकी प्रशंसनीय अंतर्राष्ट्रीय या बहुभाषी महत्वाकांक्षाएं हैं, जिसमें अनिवार्य रूप से सभी बड़े एंटरप्राइज़ और बहुभाषी सरकारें शामिल हैं, आर्किटेक्चर को जल्दी अंतर्राष्ट्रीयकृत करना रेट्रोफिटिंग से कहीं सस्ता है, भले ही लाभ टला हुआ हो।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

क्या हम लिंट नियमों के साथ स्ट्रिंग बाह्यीकरण को लागू करते हैं, और क्या किसी वास्तविक अनुवाद से पहले CI में स्यूडो-लोकलाइज़ेशन चलता है? वह ऋण जो अंतर्राष्ट्रीयकरण को महंगा बनाता है (हार्ड-कोडेड अंग्रेज़ी स्ट्रिंग, जोड़े गए वाक्य टुकड़े, लैटिन-लिपि धारणाएं) चुपचाप जमा होता है जब तक टूलिंग इसे कमिट के समय न रोके। लिंट नियम जो हार्ड-कोडेड उपयोगकर्ता पाठ को चिह्नित करते हैं, साथ ही CI में चलने वाला एक लंबे-पाठ उच्चारण-चिह्नित स्यूडो-लोकेल, कटाव, ओवरलैप, और एन्कोडिंग बग को तब पकड़ते हैं जब उन्हें ठीक करना सस्ता होता है। यही वह चीज़ है जो दर्जनों टीमों को बिना हर एक द्वारा प्लंबिंग का पुनर्आविष्कार किए या बाद में एक समय-सीमा पर धारणाओं को खोले बिना, कई भाषाओं में एक उत्पाद शिप करने देती है। हार्ड-कोडेड स्ट्रिंग की एक खोज लाएं और पूछें कि क्या कोई टीम आज गलती से एक शिप कर सकती है। यदि पाइपलाइन में कुछ भी इसे नहीं पकड़ेगा, तो वही वह अंतर है जिसे पहले बंद करना है।
हम विहित (canonical) डेटा कहां संग्रहीत करते हैं, और क्या प्रारूपण प्रस्तुति परत तक सीमित है? टाइमस्टैम्प को UTC के रूप में, देशों और मुद्राओं को ISO कोड के रूप में, और राशियों को आधार इकाइयों में संग्रहीत करने का अर्थ है कि कोई भी लोकेल उन्हें किनारे पर सही ढंग से प्रारूपित कर सकता है, जबकि डेटा परत में पके हुए प्रारूपण तर्क ऐसे बग पैदा करते हैं जिन्हें खोलना कष्टदायक है। सहमत हों कि तारीखें, संख्याएं, मुद्राएं, पते, और नाम केवल प्रस्तुति पर प्रारूपित किए जाते हैं, एक अच्छी तरह से परखी गई लाइब्रेरी के माध्यम से न कि हाथ से बनाए गए कोड से। यह बहुराष्ट्रीय एंटरप्राइज़ और बहुभाषी सरकारों के लिए मायने रखता है जहां एक नागरिक को अपनी ही परंपरा में सही तारीख क्रम, दशमलव विभाजक, और नाम क्रम देखना चाहिए। एक उदाहरण लाएं जिसमें आपका सिस्टम पहले से प्रारूपित मान संग्रहीत करता है और पता लगाएं कि जब एक नए लोकेल को इसे अलग ढंग से चाहिए तो क्या टूटता है। यदि डेटा और प्रस्तुति उलझे हुए हैं, तो लोकेल जोड़ने से पहले तय करें कि उन्हें कैसे सुलझाएंगे।
मशीन अनुवाद ठीक कहां स्वीकार्य है, और हमारी स्थानीयकरण पाइपलाइन को बैच के बजाय निरंतर कैसे रखा जाता है? मशीन अनुवाद कम-जोखिम, उच्च-मात्रा सामग्री के लिए तेज़ और सस्ता है लेकिन कानूनी, चिकित्सा, सुरक्षा, या ब्रांड-महत्वपूर्ण पाठ के लिए अनुपयुक्त है जहां एक गलत अनुवाद वास्तविक नुकसान पहुंचाता है, इसलिए सीमा एक स्पष्ट नीति होनी चाहिए, प्रति-टीम अनुमान नहीं। इसी तरह, स्थानीयकरण को एक लॉन्च-पूर्व बैच के रूप में मानना एक अनुवाद दबाव की गारंटी देता है, जबकि स्ट्रिंग को स्वचालित रूप से निकालना और एक अनुवाद प्रबंधन प्रणाली के माध्यम से समन्वयित करना हर लोकेल को वर्तमान रखता है। तय करें कि पाइपलाइन, शब्दावलियों, और उच्च-दांव स्ट्रिंग के लिए मानव-समीक्षा गेट का स्वामी कौन है। एक हालिया रिलीज़ लाएं और पूछें कि इसकी नई स्ट्रिंग को हर भाषा में दिखने में कितना समय लगा। यदि रिलीज़ों के बीच लोकेल असमन्वित हो जाते हैं, तो आपकी पाइपलाइन छुपा हुआ बैच है।
क्या हम एक दाएं-से-बाएं लोकेल और एक लंबे-पाठ स्यूडो-लोकेल का स्वचालित रूप से परीक्षण करते हैं, या हम चुपचाप लैटिन लिपियों और अंग्रेज़ी-लंबाई वाले लेआउट मान रहे हैं? द्विदिशात्मक (दाएं-से-बाएं) समर्थन और पाठ विस्तार वे धारणाएं हैं जो एक नए बाज़ार में सबसे स्पष्ट रूप से टूटती हैं: मिरर किए गए इंटरफ़ेस जो कभी मिरर नहीं हुए, और बटन जो जर्मन या फ़िनिश के अंग्रेज़ी से चालीस प्रतिशत लंबे चलने पर कट जाते हैं। प्रतिस्पर्धी खिंचाव गति है, क्योंकि भौतिक के बजाय तार्किक लेआउट गुणों पर बनाना और एक उच्चारण-चिह्नित स्यूडो-लोकेल को निरंतर एकीकरण (CI) में जोड़ना किसी वास्तविक ग्राहक की ज़रूरत से पहले प्रयास खर्च करता है। अपनी सबसे व्यस्त स्क्रीन का एक स्क्रीनशॉट लाएं जो एक दाएं-से-बाएं लोकेल में और एक लंबे स्यूडो-लोकेल में रेंडर हुआ हो, और ओवरलैप, कटे हुए लेबल, और अटके हुए तीरों को गिनें। एक बहुराष्ट्रीय एंटरप्राइज़ या एक सरकार के लिए जो कानूनी रूप से एक दाएं-से-बाएं या अल्पसंख्यक भाषा की सेवा करने के लिए बाध्य है, एक लेआउट जो मिरर नहीं हो सकता वह कोई सौंदर्य दोष नहीं है, यह एक बाज़ार या वैधानिक दायित्व है जिसे आप बिना पुनर्निर्माण के पूरा नहीं कर सकते।
उत्पाद के कौन से हिस्से वैश्विक रूप से स्थिर हैं और कौन से क्षेत्र के अनुसार लचीले हैं, और निर्णय लेने का अधिकार किसके पास है? स्थानीयकरण सांस्कृतिक है, केवल भाषाई नहीं, इसलिए रंग, चित्रण, उदाहरण, सम्मानसूचक शब्द, और यहां तक कि कौन सी सुविधाएं दी जाती हैं यह बाज़ार के अनुसार अलग हो सकता है, फिर भी आप जो भी क्षेत्रीय प्रकार अनुमति देते हैं वह हमेशा के लिए बनाने, अनुवाद करने, समीक्षा करने, और बनाए रखने के लिए एक और कलाकृति है। तनाव स्थानीय फिट, जो विश्वास और रूपांतरण बनाता है, और स्थिरता, जो ब्रांड को सुसंगत और रखरखाव भार को सीमित रखता है, के बीच है। एक ठोस सूची लाएं कि एक प्रस्तावित नया लोकेल अनुवादित स्ट्रिंग से परे क्या बदलेगा, और हर प्रकार के चालू रखरखाव की कीमत लगाएं, न केवल उसके पहले निर्माण की। एक बड़े एंटरप्राइज़ में इस निर्णय को एक नामित स्वामी चाहिए ताकि क्षेत्रीय टीमें उत्पाद को यूं ही अलग न कर सकें, और सरकार में इसे कानूनी और एक्सेसिबिलिटी सामग्री नियमों का सम्मान करना चाहिए जो क्षेत्राधिकार के अनुसार अलग होते हैं और वैकल्पिक नहीं हैं।
हम वास्तव में किन लोकेल के लिए प्रतिबद्ध हैं, हम उनमें शब्दावली को संगत कैसे रखते हैं, और उस सूची को क्या प्रमाण चलाता है? एक भाषा जोड़ने का वादा करना आसान है और बनाए रखना महंगा है, क्योंकि हर एक को एक शब्दावली, एक शैली गाइड, उच्च-दांव स्ट्रिंग के लिए मानव समीक्षा, और सही बहुवचन और लिंग हैंडलिंग चाहिए जिसे नैव एकवचन-या-बहुवचन तर्क अधिकांश भाषाओं में गलत कर देता है। प्रतिस्पर्धी विचार पहुंच बनाम लागत हैं: एक बाज़ार या आबादी जिसकी बुरी तरह सेवा की जाती है वह बिल्कुल सेवा न किए जाने से भी बदतर हो सकती है। हर उम्मीदवार लोकेल के पीछे की आबादी या राजस्व, आपकी लाइब्रेरी इसके लिए जो बहुवचन-नियम और प्रारूपण कवरेज प्रदान करती है, और इसकी शब्दावली का स्वामी कौन है, लाएं। एक बहुराष्ट्रीय एंटरप्राइज़ के लिए चालक संबोध्य बाज़ार और प्रति भाषा समर्थन लागत है, जबकि सरकार के लिए यह कानूनी भाषा-पहुंच दायित्व और समानता है, उन निवासियों की संख्या से मापा जाता है जो केवल उसी भाषा में लेनदेन कर सकते हैं।

क्षेत्रीय दृष्टिकोण

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

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

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

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

उदाहरण

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

एंटरप्राइज़। एक वैश्विक ई-कॉमर्स कंपनी ने अपने प्लेटफ़ॉर्म को जल्दी अंतर्राष्ट्रीयकृत किया: पूरी तरह UTF-8, बाह्यीकृत स्ट्रिंग, एक लोकेल-जागरूक प्रारूपण लाइब्रेरी, और अनुवाद मेमोरी व प्रति-भाषा शब्दावलियों वाली एक निरंतर स्थानीयकरण पाइपलाइन। एक नए बाज़ार में प्रवेश करना ज़्यादातर एक सामग्री अभ्यास (अनुवाद करें, समीक्षा करें, चित्रण समायोजित करें) बन गया न कि एक इंजीनियरिंग परियोजना, जिससे कंपनी को नए लोकेल में हफ्तों में लॉन्च करने की सुविधा मिली। तार्किक लेआउट गुणों पर बना दाएं-से-बाएं समर्थन का अर्थ था कि अरबी और हिब्रू बाज़ारों को बहुत कम नया UI काम चाहिए था।

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

व्यावसायिक मामला: प्रेरणाएं, ROI, और TCO

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

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

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

एंटी-पैटर्न और नुकसान

हार्ड-कोडेड स्ट्रिंग: कोड में पका हुआ उपयोगकर्ता पाठ, जो प्रति-लोकेल कोड परिवर्तनों के लिए मजबूर करता है।
स्ट्रिंग संयोजन: टुकड़ों से वाक्य बनाना, जो व्याकरण और शब्द क्रम को तोड़ता है।
गैर-यूनिकोड धारणाएं: एन्कोडिंग बग, मोजिबाके (बेमेल वर्ण एन्कोडिंग से विकृत पाठ), और लिपियों को निरूपित करने में असमर्थता।
अंग्रेज़ी पाठ लंबाई मान लेना: लेआउट जो अनुवाद होने पर कट जाते हैं या ओवरलैप होते हैं।
दाएं-से-बाएं की अनदेखी: भौतिक बाएं/दाएं लेआउट का उपयोग करना जो मिरर नहीं हो सकता।
नैव बहुवचनीकरण: एकवचन/बहुवचन तर्क जो अधिकांश भाषाओं में गलत है।
लोकेल-अंधा प्रारूपण: हार्ड-कोडेड तारीख, संख्या, और मुद्रा प्रारूप।
संदर्भ के बिना अनुवाद करना: अनुवादक अर्थ का अनुमान लगाते हैं, त्रुटियां पैदा करते हैं।
बैच, अंतिम-क्षण स्थानीयकरण: एक निरंतर पाइपलाइन के बजाय एक लॉन्च-पूर्व दबाव।
सांस्कृतिक असंवेदनशीलता: चित्रण, रंग, या उदाहरण जो स्थानीय रूप से आपत्तिजनक या भ्रामक हैं।

परिपक्वता मॉडल

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

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

स्तर 3: मानकीकृत करें। एक साझा i18n आर्किटेक्चर और लोकेल-जागरूक प्रारूपण लाइब्रेरी पूरे संगठन में दस्तावेज़ीकृत, लागू मानक है। स्ट्रिंग बाह्यीकरण को लिंट नियमों द्वारा जांचा जाता है, एक अनुवाद प्रबंधन प्रणाली और निरंतर पाइपलाइन शब्दावलियों और अनुवाद मेमोरी के साथ जगह पर है, और स्यूडो-लोकलाइज़ेशन प्लस बहु-लोकेल परीक्षण (एक दाएं-से-बाएं और एक लंबे-पाठ लोकेल सहित) CI में चलता है।

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

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

चर्चा के लिए विचार

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

मुख्य बातें

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

संदर्भ और आगे का पठन

The Unicode Consortium, The Unicode Standard and Common Locale Data Repository (CLDR)
W3C Internationalization (i18n) Activity, तकनीकें और सर्वोत्तम प्रथाएं
Richard Ishida, W3C internationalization articles and tutorials
Bert Esselink, A Practical Guide to Localization
John Yunker, Beyond Borders: Web Globalization Strategies
Unicode Technical Standard #35 (locale data markup) and ICU library documentation
IETF BCP 47 language tags
सरकारी बहुभाषी सेवा और भाषा-पहुंच मार्गदर्शन
Nielsen Norman Group and W3C articles on RTL, text expansion, and localization UX