जावास्क्रिप्ट अनुप्रयोगों के अंतर्राष्ट्रीयकरण पर जॉन रेजिग

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

मुझे अक्सर बहुभाषी साइटों का उपयोग करना पड़ता था या दुनिया भर से अंग्रेजी भाषा की साइटों पर जाना पड़ता था, इसलिए मुझे उन आवश्यकताओं का एक अच्छा विचार था जो अंतर्राष्ट्रीयकरण को संतुष्ट करना चाहिए:

• भाषाओं के बीच पूर्ण समानता। वही सामग्री सभी के लिए उपलब्ध होनी चाहिए।
• विभिन्न भाषा संस्करणों को उप-डोमेन में समाहित किया जाना चाहिए। विभिन्न भाषाओं के लिए अलग-अलग शीर्ष-स्तरीय डोमेन का उपयोग करना बहुत महंगा है, और आवश्यक नहीं है। इसके अलावा, एड्रेस बार को संपादित करके भाषाओं के बीच स्विच करना अधिक सुविधाजनक है।
• कोई स्वचालित अनुवाद नहीं। सर्वर द्वारा मशीन अनुवाद वक्र स्थापित करने के कारण किसी साइट के अपठनीय संस्करण पर ठोकर खाने से बुरा कुछ नहीं है, यह आपके आईपी या कंप्यूटर भाषा सेटिंग्स द्वारा निर्देशित है। एक ही URL को हमेशा एक ही भाषा संस्करण में इंगित करना चाहिए।
• साइट के राष्ट्रीय संस्करण में कोई भी स्वचालित रीडायरेक्ट नहीं होता है। पिछले पैराग्राफ के समान कारणों के लिए - अगर मैं foo.com पर जाता हूं, तो मुझे मुझे es.foo.com पर भेजने की जरूरत नहीं है, क्योंकि सर्वर ने फैसला किया कि मैं स्पेन से था। इसके बजाय, मेरी मूल भाषा में (संभवतः) अधिसूचना को दिखाना और मैन्युअल रूप से राष्ट्रीय संस्करण पर स्विच करने की पेशकश करना बेहतर है।

अंत में, आपको इस संरचना की तरह कुछ मिलना चाहिए:

• domain.com - मुख्य (अंग्रेजी) संस्करण;
• ja.domain.com - जापानी संस्करण;
• XX.domain.com - अन्य भाषाएँ।

भाषाओं के बीच समानता और उप-डोमेन का उपयोग किसी भी पृष्ठ की भाषाओं के बीच स्विच करना संभव बनाता है बस एक राष्ट्रीय उप-डोमेन जोड़कर:

• domain.com/search?q=mountain
• ja.domain.com/search?q=mountain

दोनों पृष्ठों को काम करना चाहिए और समान दिखना चाहिए सिवाय इसके कि दूसरा जापानी में होगा।

पेज हेडर में, मैं आसानी से उसी पेज का लिंक दूसरी भाषा में डाल सकता हूं:



वैकल्पिक रूप से, आप Google खोज इंजन को मेरी साइट की संरचना को बेहतर ढंग से समझने में मदद करने के लिए rel = "वैकल्पिक" hreflang = "x" तकनीक का उपयोग कर सकते हैं। यदि मैं इस पंक्ति को पृष्ठ शीर्षक में डालता हूं, तो Google खोज परिणामों में स्थानीयकृत संस्करण दिखाएगा।

<link rel="alternate" hreflang="ja" href="http://ja.domain.com/" /> 

सर्वर साइड

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



जैसा कि यह निकला, इसे लागू करना इतना आसान नहीं है। सबसे आसान तरीका है अनुरोध हेडर के स्वीकृत भाषा क्षेत्र में देखना, लेकिन यह केवल तभी काम करता है जब आपका पृष्ठ पूरी तरह से गतिशील हो और कभी कैश न हो।

यदि नहीं, तो आपको यह विचार करने की आवश्यकता है कि कैश कैसे और कहां से जुड़ा है।

मेरे मामले में, मैंने कई Node / Express सर्वर के सामने Nginx का उपयोग किया। इसका मतलब यह है कि नोड पर जारी किए गए एप्लिकेशन सर्वर को सब कुछ कैश किया गया था, जिसमें भाषा को स्विच करने के प्रस्ताव के साथ सूचनाएं भी शामिल थीं।

नतीजतन, आपको ग्राहक की ओर से इस अधिसूचना को प्रबंधित करना होगा। और यहां एक और बाधा हमें इंतजार कर रही है: DOM / जावास्क्रिप्ट का उपयोग करने वाले क्लाइंट पर वांछित भाषा का मज़बूती से निर्धारण करना असंभव है।

इसलिए, हमें सर्वर को अतिरिक्त रूप से वांछित भाषा के बारे में एप्लिकेशन को सूचित करना होगा।

इसके लिए, मैंने Nginx AcceptedLanguage मॉड्यूल का उपयोग किया। मैंने वांछित भाषा के साथ एक कुकी सेट की और इसे ग्राहक को दिया। यहाँ Nginx विन्यास कैसा दिखता है:

 set_from_accept_language $lang en ja; add_header Set-Cookie lang=$lang; 

अब ग्राहक के हिस्से में करने के लिए जो कुछ भी बचा था वह कुकी को पढ़ना था और अगर वांछित भाषा पृष्ठ की भाषा से मेल नहीं खाती थी तो एक अधिसूचना प्रदर्शित करना था।

इस प्रकार, Nginx सभी सामग्री को आक्रामक रूप से कैश करना जारी रखता है, और क्लाइंट सही ढंग से एक संदेश प्रदर्शित करता है जो उसे पृष्ठ के स्थानीयकृत संस्करण पर जाने के लिए कहता है।

अंतर्राष्ट्रीयकरण का तर्क

मैंने अंतर्राष्ट्रीयकरण के लिए अपना Node.js मॉड्यूल लिखा। वह निम्नलिखित रणनीति का उपयोग करता है:

• सभी अनुवाद JSON प्रारूप में फ़ाइलों में संग्रहीत हैं;
• ये फाइलें उपयोग के समय मक्खी पर अनुवाद के लिए उपयोग की जाती हैं;
• अनुवाद __("Some string") को बुलाकर आम तौर पर स्वीकृत तरीके से किया जाता है। यदि कोई अनुवाद मौजूद है, तो स्ट्रिंग "Some string" को अनुवाद द्वारा प्रतिस्थापित किया जाता है, यदि नहीं, तो इसका उपयोग सीधे किया जाता है।

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

यदि आने वाला अनुरोध अंतर्राष्ट्रीयकरण के सामान्य उद्देश्य के लिए पसंदीदा भाषा सेट करता है, तो इससे सर्वर को किसी अन्य अनुरोध के जवाब में एक गलत भाषा संस्करण जारी हो सकता है:



कम से कम, आपको यह सुनिश्चित करने की आवश्यकता है कि वर्तमान अनुरोध के निष्पादन के दौरान पसंदीदा भाषा के बारे में जानकारी खो नहीं जाती है (यह मेरे मॉड्यूल में लागू है)।

व्यवहार में, इसका मतलब यह है कि आपको i18n संपत्ति को request ऑब्जेक्ट में जोड़ना होगा, जैसे कि मिडलवेयर आमतौर पर एक्सप्रेस में जोड़ा जाता है:

 app.use(function(req, res, next) { req.i18n = new i18n(/* options... */); next(); }); 

काम का संगठन

अंतर्राष्ट्रीयकरण का तर्क विकास मोड और उत्पादन में अलग तरह से व्यवहार करता है।

विकास मोड में:

• अनुवाद फाइलें हर अनुरोध के साथ डाउनलोड की जाती हैं;
• अनुवाद फ़ाइलों को किसी भी परिवर्तन के बाद गतिशील रूप से अपडेट किया जाता है;
• चेतावनी संदेश और डिबग संदेश प्रदर्शित होते हैं।

उत्पादन में:

• सभी अनुवाद फाइलें संचित हैं;
• फ़ाइलें कभी भी गतिशील रूप से अपडेट नहीं की जाती हैं;
• चेतावनी और डिबगिंग संदेश प्रदर्शित नहीं होते हैं।

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

कोड संगठन

लाइनें जिनकी अनुवाद की आवश्यकता है वे कहीं भी हो सकती हैं: एप्लिकेशन कोड, टेम्प्लेट और यहां तक ​​कि (भगवान न करे!) शैलियाँ।

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

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

मेरे आवेदन में एकमात्र अपवाद जब कोड में अनुवाद योग्य तार होते हैं, एक्सप्रेस दृश्य कोड होता है, जहां मैं अनुरोध से जुड़ी i18n वस्तु का उपयोग करता हूं:

 module.exports = { index: function(req, res) { req.render("index", { title: req.i18n.__("My Site Title"), desc: req.i18n.__("My Site Description") }); } }; 

मैं स्विग टेम्पलेट इंजन का उपयोग करता हूं, लेकिन अनुवाद तकनीक किसी भी टेम्पलेट इंजन के लिए लगभग समान होगी:

 {% extends "page.swig" %} {% block content %} <h1>{{ __("Welcome to:") }} {{ title }}</h1> <p>{{ desc }}</p> {% endblock %} 

__(...) कॉल में लिपटे एक स्ट्रिंग को अनुवाद के साथ बदल दिया जाता है।

वास्तव में अनुवाद

अब तक, मैं तृतीय-पक्ष के अनुवादकों की सहायता के बिना, अपने आवेदन का स्वयं अनुवाद कर रहा हूं। आवेदन अभी भी बहुत छोटा है, अनुवाद के लिए केवल कुछ दर्जन लाइनें हैं।

मैं कुछ ट्रिक्स साझा कर सकता हूं जो आपको पेशेवर अनुवादक के बिना लंबे समय तक चलने में मदद कर सकते हैं:

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

निष्कर्ष

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