परिदृश्य
आप पोलैंड में स्थित एक ऑनलाइन स्टोर के मालिक हैं। आपके अधिकांश ग्राहक पोलैंड से हैं और वे पोलिश बोलते हैं। लेकिन आप अपने उत्पादों को विदेशों में भी बेचना चाहते हैं और आपके अंतरराष्ट्रीय ग्राहक मुख्य रूप से अंग्रेजी बोलते हैं। इसलिए आप चाहते हैं कि आपका ऑनलाइन स्टोर पोलिश . दोनों में उपलब्ध हो और अंग्रेज़ी . आप यह भी उम्मीद करते हैं कि आपके उत्पाद फ़्रांस में अच्छी तरह से बिकेंगे, इसलिए आप अनुमान लगाते हैं कि आपको एक फ़्रेंच तैयार करना होगा स्टोर का संस्करण भी (और शायद स्पेनिश भी, क्योंकि क्यों नहीं?)।
आप चाहते हैं कि आपके उपयोगकर्ता पोलिश संस्करण से स्विच कर सकें
अंग्रेजी संस्करण के लिए और पीछे।
और स्पष्ट रूप से आप चाहते हैं कि उत्पाद विवरण पोलिश से अंग्रेजी में स्विच हो जाए।
आप एक बहु-भाषा वेब एप्लिकेशन कैसे बनाते हैं?
आपके आवेदन में दो प्रकार के पाठ हैं। एक स्थिर है डेटा:बटन लेबल, टेबल हेडर, ग्राफिक्स (जिसमें अक्सर टेक्स्ट होता है)। दूसरा उपयोगकर्ता द्वारा परिभाषित . है डेटा, जैसे उत्पाद का नाम, उत्पाद मूल्य, उत्पाद विवरण आदि। डेटा सामान्य रूप से डेटाबेस से लिया जाता है।
स्थिर डेटा वह है जिसे आप अपने आउटपुट में स्ट्रिंग अक्षर के रूप में लिखना चाहते हैं। उपयोगकर्ता-परिभाषित डेटा वह डेटा होता है जिसे आप अपने डेटाबेस से लेते हैं।
मैं आज स्थिर डेटा के बारे में बात नहीं करूंगा। कोई भी उचित वेब ढांचा स्थिर डेटा के अंतर्राष्ट्रीयकरण को संभालेगा। विवरण के लिए अपने वेब एप्लिकेशन ढांचे के दस्तावेज़ीकरण से परामर्श लें। "अंतर्राष्ट्रीयकरण," "i18n," "स्थानीयकरण," या "अनुवाद" जैसे कीवर्ड देखें।
आज मैं बात करूंगा कि बहु-भाषा डेटा को संभालने के लिए हम आमतौर पर ई-पॉइंट पर किस डेटाबेस संरचना का उपयोग करते हैं। आपके स्टोर के डेटाबेस में, संभवतः आपके पास product
तालिका जो स्टोर में उपलब्ध सभी उत्पादों के बारे में जानकारी संग्रहीत करती है।
product
तालिका में name
. जैसे कॉलम हैं , description
, और price
. जब आप उत्पाद जानकारी का दूसरी भाषाओं में अनुवाद करते हैं, तो आपको केवल कुछ कॉलम का अनुवाद करना होता है। यहां आप केवल name
. का अनुवाद करेंगे और description
, लेकिन price
जब आप भाषा बदलते हैं तो नहीं बदलता है।
जब हम अनेक भाषाओं के लिए समर्थन जोड़ते हैं तो हम language_version
, जो स्टोर में उपलब्ध सभी भाषा संस्करणों को संग्रहीत करता है। हम आमतौर पर code
. नामक कॉलम जोड़ते हैं और एक जिसे is_default
. कहा जाता है (एक उपयुक्त बाधा के साथ:केवल एक संस्करण ही डिफ़ॉल्ट हो सकता है)।
इसके बाद, हम product
तालिका को दो तालिकाओं में विभाजित करें:तालिका product
और तालिका product_lv
. प्रत्येक उत्पाद के लिए, product
product_lv
टेबल; प्रत्येक भाषा संस्करण के लिए एक पंक्ति। तालिका product_lv
केवल कॉलम हैं जिनका अनुवाद किया जाना है:name
और description
. भाषा-स्वतंत्र कॉलम (जैसे price
, क्योंकि आप एक ही कीमत पर बेचते हैं, भले ही आपका ग्राहक अंग्रेजी या पोलिश बोलता हो) तालिका में बने रहें product
।
हम प्रत्येक तालिका के लिए ऐसा ही करते हैं जिसमें अनुवादित डेटा होता है। अनुवादित डेटा table_lv
तालिका, भाषा-स्वतंत्र डेटा मुख्य तालिका में रहता है।
पेशेवरों और विपक्ष
एक स्पष्ट नुकसान यह है कि सभी बनाने, पुनर्प्राप्त करने, अपडेट करने या हटाने (सीआरयूडी) संचालन थोड़ा अधिक जटिल हो जाते हैं। सही विवरण प्राप्त करने के लिए आपको हमेशा एक अतिरिक्त भाषा संस्करण तालिका के साथ जुड़ना होगा।
इस डिज़ाइन का लाभ यह है कि जब आप कोई नया भाषा संस्करण जोड़ते हैं तो आपको अपना डेटाबेस स्कीमा बदलने की आवश्यकता नहीं होती है। मैं यह नहीं कह रहा हूं कि एक नया भाषा संस्करण जोड़ना आसान है। आखिरकार, आपको सभी उत्पाद विवरणों का अनुवाद करना होगा। यह एक संगठनात्मक चुनौती है लेकिन डेटाबेस के दृष्टिकोण से यह काफी आसान है:ढेर सारे इंसर्ट।
आप अपने बहु-भाषा डेटाबेस को कैसे डिज़ाइन करते हैं?