स्थानीयकरण-तैयार प्रणाली कैसे डिज़ाइन करें

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

स्थानीयकरण क्या है?

स्थानीयकरण किसी उत्पाद को विभिन्न बाजारों में ढालने की प्रक्रिया है। उत्पाद की बिक्री के मामले में अधिकतम बाजार हिस्सेदारी हासिल करने में यह एक प्रमुख कारक है। जब स्थानीयकरण सही ढंग से किया जाता है, तो उपयोगकर्ता महसूस करेंगे कि उत्पाद उनकी भाषा, संस्कृति और जरूरतों के लिए बनाया गया था।

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

स्थानीयकरण न करने पर आप क्या खो सकते हैं?

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

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

सामग्री अनुवाद स्थानीयकरण के रूप में

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

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

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

दृष्टिकोण 1 - प्रत्येक इच्छित फ़ील्ड के लिए अलग भाषा कॉलम जोड़ना

विकास की दृष्टि से यह सबसे सरल उपाय है। इसे प्रत्येक क्षेत्र के लिए एक भाषा कॉलम जोड़कर कार्यान्वित किया जा सकता है।

पेशेवरों

• इसे लागू करना बहुत आसान है।

• किसी भी भाषा में अंतर्निहित डेटा लाने के लिए SQL लिखने में कोई जटिलता नहीं है। मान लीजिए कि मैं फ्रेंच भाषा में किसी विशेष ऑर्डर के लिए उत्पाद और ग्राहक विवरण पुनर्प्राप्त करने के लिए एक प्रश्न लिखना चाहता हूं। कोड इस तरह दिखेगा:

  Select p.product_name_FR, p.description_FR, p.price, 
         c.name_FR, c.address_FR, c.contact_name 
  from order_line o, product p, customer c
  	Where o.product_id = p.id and o.customer_id = c.id
  	And id = ;
  

विपक्ष

• कोई मापनीयता नहीं है:हर बार जब कोई नई भाषा जोड़ी जाती है, तो तालिकाओं में दर्जनों अतिरिक्त कॉलम जोड़ने की आवश्यकता होती है।
• इसमें समय लग सकता है, खासकर यदि कई क्षेत्रों में एक से अधिक भाषाओं की आवश्यकता हो।

• डेवलपर्स सभी मौजूदा भाषाओं को प्रबंधित करने के लिए नीचे दिखाए गए प्रश्न को लिखते हैं। इसलिए, जब कोई नई भाषा पेश की जाती है, तो आपके एप्लिकेशन के सभी SQL को बदलना होगा। (नोट: @in_language आवेदन की वर्तमान भाषा को दर्शाता है; यह पैरामीटर ऐप के फ्रंट एंड से आता है, जबकि बैक एंड रिकॉर्ड्स को पुनः प्राप्त कर रहा है।)

  SELECT CASE @in_language 
                WHEN ‘FR’ THEN p.product_name_FR
                WHEN ‘DE’ THEN p.product_name_DE
                DEFAULT THEN p.product_name_EN,
             p.price,
            CASE @in_language 
                WHEN ‘FR’ THEN c.name_FR
                WHEN ‘DE’ THEN c.name_DE
                DEFAULT THEN c.name_EN,
            c.contact_name
  FROM order_line o, product p, customer c
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND id = ;
  

दृष्टिकोण 2 - अनुवादित पाठ के लिए एक अलग तालिका बनाना

इस दृष्टिकोण में, अनुवादित पाठ को संग्रहीत करने के लिए एक अलग तालिका का उपयोग किया जाता है; नीचे दिए गए उदाहरण में, हमने इस तालिका को translation . इसमें प्रत्येक भाषा के लिए एक कॉलम होता है। फ़ील्ड मानों से सभी लागू भाषाओं में अनुवादित मान रिकॉर्ड के रूप में संग्रहीत किए जाते हैं। वास्तविक अनुवादित पाठ को अंतर्निहित तालिकाओं में संग्रहीत करने के बजाय, हम इसके संदर्भ को translation टेबल। यह कार्यान्वयन हमें मौजूदा डेटा मॉडल में बहुत अधिक परिवर्तन किए बिना अनुवादित पाठ का एक सामान्य भंडार बनाने की अनुमति देता है।

पेशेवरों

• अगर स्थानीयकरण को मौजूदा डेटा मॉडल पर लागू करना है तो यह एक अच्छा तरीका है।
• translation एक नई भाषा पेश किए जाने पर केवल तालिका में बदलाव की आवश्यकता होती है।
• जब मूल पाठ सभी तालिकाओं में समान होता है, तो कोई निरर्थक अनुवादित पाठ नहीं होता है। उदाहरण के लिए:मान लें कि ग्राहक का नाम और उत्पाद का नाम समान है। इस मामले में, अनुवाद तालिका में केवल एक रिकॉर्ड डाला जाएगा, और एक ही रिकॉर्ड को customer और product टेबल.

विपक्ष

• इसे अभी भी डेटा मॉडल में बदलाव की आवश्यकता है।
• तालिका में अनावश्यक NULLs हो सकते हैं। यदि केवल एक समर्थित भाषा के लिए 1,000 फ़ील्ड की आवश्यकता होती है, तो आप 1,000 रिकॉर्ड - और ढेर सारे NULLs बनाते हैं।

• जैसे-जैसे जॉइन की संख्या बढ़ती है, SQL लिखने की जटिलता बढ़ती जाती है। और जब translation तालिका, पुनर्प्राप्ति समय धीमा है।

  आइए फिर से भाषा-प्रबंधन समस्या विवरण के लिए एक SQL लिखें:

  SELECT CASE @in_language 
                WHEN ‘FR’ THEN tp.text_FR
                WHEN ‘DE’ THEN tp.text_DE
                DEFAULT THEN p.product_name_EN,
             p.price,
            CASE @in_language 
                WHEN ‘FR’ THEN tc.text_FR
                WHEN ‘DE’ THEN tc.text_DE
                DEFAULT THEN c.name_EN,
            c.contact_name
  FROM order_line o, product p, customer c, translation tp, translation tc
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND p.name_translation_id = tp.id
  	AND c.name_translation_id = tc.id
  	AND id = ;
  
  

अनुवाद तालिका दृष्टिकोण पर एक प्रकार

जब अनुवादित पाठ पुनर्प्राप्त किया जा रहा हो तो बेहतर प्रदर्शन प्राप्त करने के लिए, हम translation एकाधिक तालिकाओं में तालिका। हम डोमेन के आधार पर रिकॉर्ड्स को समूहबद्ध कर सकते हैं, यानी customer , product , आदि

दृष्टिकोण 3 - प्रत्येक भाषा के लिए पंक्तियों वाली एक अनुवाद तालिका

यह कार्यान्वयन दूसरे दृष्टिकोण के समान है, लेकिन यह अनुवादित पाठ के मानों को स्तंभों के बजाय पंक्तियों में संग्रहीत करता है। यहां, translation तालिका आईडी किसी भी अनुवादित भाषा में फ़ील्ड मान के लिए समान रहती है। एक संयुक्त प्राथमिक कुंजी {id , language_id } को अनुवाद तालिका में संग्रहीत किया जाता है, और यह वही translation_id संग्रहीत करता है एकाधिक language_id . के विरुद्ध प्रत्येक फ़ील्ड के लिए .

पेशेवरों

• यह कार्यान्वयन डेवलपर्स को डेटा-पुनर्प्राप्ति SQL को आसानी से लिखने की अनुमति देता है।
• इस मॉडल के लिए ओईएम लिखना भी आसान है।
• जब आप कोई नई भाषा जोड़ते हैं तो डेटा मॉडल में किसी बदलाव की आवश्यकता नहीं होती है; बस नई भाषा के लिए रिकॉर्ड डालें।
• कोई अनावश्यक मेमोरी खपत नहीं होती है जब फ़ील्ड का एक सेट किसी भाषा पर लागू नहीं होता है।

• डेटा-पुनर्प्राप्ति SQL की जटिलता कम हो जाती है। नीचे दिए गए उदाहरण को देखें:

  SELECT tp.text,
          p.price,
         tc.text,
          c.contact_name
  FROM order_line o, product p, customer c, translation tp, 
       translation tc, language l
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND p.name_translation_id = tp.id
  	AND c.name_translation_id = tc.id
               AND tp.language_id = l.id
               AND tc.language_id = l.id
               AND l.name = @in_language
  	AND id = ;
  
  

विपक्ष

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

क्या होगा यदि हम दृष्टिकोण 2 और 3 को मिला दें?

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

दृष्टिकोण #4 - अनूदित फ़ील्ड और गैर-अनुवादित फ़ील्ड के लिए निकाय परतें बनाना

इस समाधान में, एक या अधिक अनुवादित फ़ील्ड वाली निकाय तालिकाएँ दो परतों में विभाजित होती हैं:एक अनूदित फ़ील्ड के लिए, और दूसरी गैर-अनुवादित फ़ील्ड के लिए। इस तरह, हम प्रत्येक के लिए अलग-अलग परतें बनाते हैं।

पेशेवर

• अनुवाद तालिका में शामिल होने की कोई आवश्यकता नहीं है यदि केवल गैर-अनुवादित फ़ील्ड का संबंध है। इसलिए, गैर-अनुवादित क्षेत्रों को बेहतर प्रदर्शन मिलता है।
• अनुवादित पाठों को पुनः प्राप्त करने के लिए अपेक्षाकृत कम संख्या में जुड़ने की आवश्यकता है।
• OEM लिखना आसान है।
• अनुवादित पाठ को पुनः प्राप्त करने के लिए SQL सरल हैं।
• यह सभी संस्थाओं में एकाधिक भाषाओं को शामिल करने के लिए एक सिद्ध दृष्टिकोण है।

बात को प्रदर्शित करने के लिए, यहाँ एक नमूना प्रश्न है जो अनुवादित पाठ को पुनः प्राप्त करेगा:

SELECT pt.product_name, pt.description, p.price
FROM order_line o, product p, product_translation pt, language l
	WHERE o.product_id = p.id AND 
	AND p.id = pt.product_non_trans_id
	AND pt.language_id = l.id
               AND l.name = @in_language
	AND id = ;

स्थानीयकरण - सामग्री अनुवाद से परे जाना

स्थानीयकरण केवल आपकी एप्लिकेशन सामग्री का दूसरी भाषा में अनुवाद नहीं कर रहा है। सांस्कृतिक और कार्यात्मक मानदंड हैं जिन पर भी ध्यान देने की आवश्यकता है। उदाहरण के लिए, उत्तरी अमेरिका में दिनांक मान को 'MM/DD/YYYY' के रूप में स्वरूपित किया जाता है, लेकिन अधिकांश एशिया में इसे 'DD/MM/YYYY' के रूप में लिखा जाता है।

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

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

स्थानीयकरण के बारे में एक और विचार

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

किसी एप्लिकेशन को स्थानीय रूप से अनुकूल बनाने के लिए और क्या किया जा सकता है? हमें टिप्पणियों में अपने विचार बताएं।