हम बहु-क्षेत्रीय साइटों के निर्माण से निपटते हैं

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

URL निर्माण विकल्प

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

1. किसी अन्य डोमेन पर साइट का संस्करण:

example.com, example.ru 

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

2. उपडोमेन पर साइट का संस्करण:

 ru.example.com, ua.example.com 

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


3. एक उपनिर्देशिका में साइट का संस्करण:

 example.com/ru/, example.com/ua/ 

सबसे आसान तरीका है, लेकिन विभिन्न सर्वरों में विभाजित करना अधिक कठिन है।

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

एक बहु-क्षेत्रीय साइट की अवधारणा

इसलिए, हम एक ऐसी साइट बनाना चाहते हैं जो रूस, यूक्रेन और संयुक्त राज्य अमेरिका में काम करेगी। जिन भाषाओं में हमारी साइट संचालित होगी, वे रूसी, यूक्रेनी और अंग्रेजी होंगी। URL संरचना बनाने के लिए, हम तीसरा विकल्प लेते हैं।

आमतौर पर, काम की सरल और सीमित योजनाएं Google और यैंडेक्स के उदाहरणों में दिखाई देती हैं, जैसे: संयुक्त राज्य अमेरिका में हम अंग्रेजी में साइट दिखाते हैं, रूस में - रूसी में, फ्रांस में - फ्रेंच में, और इसी तरह:

 example.com/en-us/ example.com/ru-ru/ example.com/fr-fr/ 

हालांकि, वास्तविक जीवन में, नए सवाल उठते हैं। और यूक्रेन के लिए क्या करना है, हम किस भाषा को दिखाएंगे? रूसी और यूक्रेनी हैं। ठीक है, कोई बात नहीं, एक नया गुच्छा जोड़ें

 example.com/uk-ua/ 

और अगर आपको कनाडा में भी साइट का एक संस्करण चलाने की आवश्यकता है? अंग्रेजी और फ्रेंच के साथ अधिक विकल्प जोड़ें:

 example.com/en-ca/ example.com/fr-ca/ 

संक्षेप में, हम यह पता लगाते हैं कि हमें किन भाषाओं की आवश्यकता है और "भाषा - देश" संयोजकों को जोड़ने की आवश्यकता है।

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

Microsoft: www.microsoft.com/home/en-ca/locale.aspx
Apple: www.apple.com/choose-your-country
IBM: www.ibm.com/planetwide/select/selector.html

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

आप्रवासियों और अत्यधिक मोबाइल लोगों के साथ समस्या

वापस हमारे मूल उदाहरण पर। जाहिर है, कई रूसी बोलने वाले अमरीका में रहते हैं और उनमें से कई आपकी साइट के रूसी संस्करण के साथ काम करना पसंद करेंगे। विकल्प "उन्हें साइट के रूसी संस्करण पर स्विच करने दें, उदाहरण.com/ru-ru/", क्योंकि वे देखना चाहते हैं, उदाहरण के लिए, डॉलर में आपकी साइट पर कीमतें, अमेरिकी फोन नंबर, पता और अन्य संपर्क जानकारी देखें, सामान्य तौर पर, सब कुछ देखें। example.com/en-us/ विज़िटर देखते हैं, लेकिन एक ही समय में सब कुछ रूसी में होना चाहिए।

ठीक है, आप देश के साथ भाषा का एक और गुच्छा बना सकते हैं:

 example.com/ru-us/ 

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

 example.com/uk-us/ 

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

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

रूस - रूसी
यूक्रेन - यूक्रेनी

और वह यह है! "यूक्रेन - रूसी" चुनने का कोई तरीका नहीं है, इस तथ्य के बावजूद कि अधिकांश आबादी रूसी बोलती है। यदि Microsoft किसी भी देश के लिए सभी संभव भाषाओं की पेशकश करता है, तो उसे चयन पृष्ठ पर 93 × 38 = 3534 भाषा-देश लिंक रखना होगा। स्वाभाविक रूप से, यह पता लगाना मुश्किल होगा कि पाठ की ऐसी शीट वाले पृष्ठ पर आपको क्या चाहिए।

उल्लिखित Apple और IBM के लिए एक समान कठोर संरचना काम करती है।

और निष्कर्ष क्या है?

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

और खोज इंजन इस विविधता का जवाब कैसे देंगे?

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

 <link rel="alternate" hreflang="x-default" href="http://example.com/"> <link rel="alternate" hreflang="ru-ru" href="http://example.com/ru-ru/"> <link rel="alternate" hreflang="ru-us" href="http://example.com/ru-us/"> <link rel="alternate" hreflang="ru-ua" href="http://example.com/ru-ua/"> <ink rel="alternate" hreflang="uk-ru" href="http://example.com/uk-ru/"> <ink rel="alternate" hreflang="uk-us" href="http://example.com/uk-us/"> <ink rel="alternate" hreflang="uk-ua" href="http://example.com/uk-ua/"> <link rel="alternate" hreflang="en-ru" href="http://example.com/en-ru/"> <link rel="alternate" hreflang="en-us" href="http://example.com/en-us/"> <link rel="alternate" hreflang="en-ua" href="http://example.com/en-ua/"> 

युपीडी। Microsoft के मामले में, हमें साइट के प्रत्येक पृष्ठ पर 3535 पंक्तियों को जोड़ना होगा। पृष्ठ में इतने सारे टैग न जोड़ने के लिए, उन्हें साइट मानचित्र पर रखना बेहतर है। ऐसा लगता है कि यह केवल Google के लिए काम करता है। यैंडेक्स के अनुरोध का उत्तर है: "वर्तमान में साइटमैप फ़ाइल में क्षेत्रीय लेआउट निर्दिष्ट करना हमारे द्वारा समर्थित नहीं है।"

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

 <link rel="alternate" hreflang="en-us" href="http://example.com/en-us/"> 

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

 example.com/ru-us/ 

सबसे अधिक संभावना है, उसे निम्नलिखित पृष्ठों में से एक की पेशकश की जाएगी:

 example.com/ru-ru/ 

अगर वह रूसी में खोज करता है, और

 example.com/en-us/ 

अगर वह अंग्रेजी में खोज करता है।

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

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