मुझे स्थानीयकरण (सर्वर-साइड या क्लाइंट-साइड) कहां करना चाहिए?

Question

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

मेरा प्रश्न यह है कि मुझे स्थानीयकरण कहां प्रबंधित करना चाहिए: क्या REST सेवाओं को अनुरोध प्राप्त करना चाहिए और स्थानीय डेटा के साथ उत्तर भेजना चाहिए, या ग्राहक को सामान्य डेटा प्राप्त करना और भेजना चाहिए और फिर स्थानीयकरण करने के लिए ज़िम्मेदार होना चाहिए?

Answer 1

यदि आप अनुवादित स्ट्रिंग्स के बजाय स्ट्रिंग आईडी प्रदान करते हैं तो आपका REST API दूसरों द्वारा उपयोग करना आसान होगा। एक API का उपयोग करना, जो "E_NOT_AUTHORIZED"कुछ मानव-भाषा, और यहां तक ​​कि स्थानीय स्ट्रिंग लौटाता है, की तुलना में अधिक सीधा है।

इसके अलावा, आप भविष्य के संस्करणों में स्थानीयकृत स्ट्रिंग को बदलना चाह सकते हैं, जो एक ब्रेकिंग एपीआई परिवर्तन होगा। स्ट्रिंग आईडी दृष्टिकोण के साथ, आप अभी भी "E_NOT_AUTHORIZED"अपने एपीआई को संगत रखते हुए वापस लौट जाते हैं ।

यदि आप Angular.js जैसे किसी फ्रेमवर्क का उपयोग करते हैं , तो यदि आप स्ट्रिंग आईडी दृष्टिकोण का उपयोग करते हैं तो भाषा हॉट-स्विचिंग को लागू करना आसान है। आप बस एक और स्ट्रिंग को लोड करते हैं, और सभी तार स्वचालित रूप से उनकी भाषा को बदलते हैं क्योंकि आप अपने टेम्पलेट में कुछ फ़िल्टर तर्क का उपयोग करते हैं, जैसे {{errorStringID | loc}}।

एक और विचार: अपने सर्वर लोड को कम करने के लिए, अपने बैक-एंड को यथासंभव सरल रखें। आप एक ही संख्या में सर्वर के साथ और अधिक ग्राहकों की सेवा करने में सक्षम होंगे। CDN के माध्यम से अपने स्ट्रेटेबल्स वितरित करें, और फ्रंट-एंड में स्थानीयकरण करें।

Answer 2

क्या ग्राहक Accept-Languageअनुरोधों में मानकीकृत हेडर भेजते हैं, फिर सर्वर पर स्थानीयकरण करते हैं और Content-Languageप्रतिक्रियाओं में हेडर शामिल करते हैं । जानकारी के लिए RFC 7231 सेक्शन 5.3.5 देखें।

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

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

Answer 3

यदि आप कई उपकरणों का समर्थन करने जा रहे हैं तो मैं सर्वर साइड पर जितना संभव हो उतना कहूंगा।

प्रत्येक डिवाइस निश्चित रूप से अपने आप ही कुछ अनुवादों का उपयोग करेगा, लेकिन एपीआई आदि से त्रुटि संदेश के रूप में साझा किए गए सामान डिवाइस की परवाह किए बिना समान होंगे।

Comments

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

— ग्वो

Answer 4

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