संक्षेप में जवाब
बाज़ार-दर-बाज़ार एक ढाँचा, जो अनुवादित टेक्स्ट से आगे बढ़कर स्थानीय इरादे, स्थिर अंतरराष्ट्रीय URL, वैध hreflang और व्यावसायिक रूप से सटीक ग्राहक यात्रा तक पहुँचाता है।
अनुवाद भाषा बदलता है; लोकलाइज़ेशन बाज़ार से मेल बदलता है
अनुवादित वेबसाइट व्याकरण में उत्कृष्ट और व्यावसायिक रूप से ग़लत हो सकती है। कारण यह है कि शब्द अंतरराष्ट्रीय अनुभव की केवल एक परत हैं। W3C लोकलाइज़ेशन को इंटरनेशनलाइज़ेशन से अलग करते हुए उसे लक्षित बाज़ार की भाषाई, सांस्कृतिक और अन्य आवश्यकताओं के अनुरूप ढालना बताता है। इसमें अनुवादित पाठ के साथ-साथ मुद्रा, तारीख़ और संख्या के प्रारूप, पते, क़ानूनी आवश्यकताएँ, तस्वीरें और डिज़ाइन परंपराएँ भी आ सकती हैं। खोज का इरादा एक और परत जोड़ता है: अलग-अलग बाज़ारों के लोग एक ही ज़रूरत को एक ही तरह से नहीं बताते।
यह अंतर प्रोजेक्ट के ब्रीफ़ को बदल देना चाहिए। "अंग्रेज़ी साइट का जर्मन में अनुवाद करें" यह मान लेता है कि स्रोत सूचना संरचना, ऑफ़र, उदाहरण और कन्वर्ज़न पथ वैध बने रहते हैं। "जर्मनी के लिए स्थानीय बनाएँ" यह पूछता है कि क्या बाज़ार को अलग क्वेरी भाषा, अलग प्रमाण, कीमतें, नीतियाँ, उत्पाद उपलब्धता, फ़ॉर्म, संपर्क के तरीके और संपादकीय उदाहरण चाहिए। कुछ पेज लगभग सीधे अनुवाद हो सकते हैं; कुछ को नए सिरे से गढ़ना पड़ेगा; और कुछ को स्थानीय संस्करण की ज़रूरत ही नहीं।
विफलता का ढंग यह है कि स्रोत भाषा को व्यवसाय की प्रामाणिक वास्तविकता मान लिया जाए और बाक़ी हर बाज़ार को उसका व्युत्पन्न। अंतरराष्ट्रीय सर्च प्रोजेक्ट तब बेहतर चलते हैं जब हर बाज़ार का एक उत्तरदायी संपादक हो जो स्रोत पेज पर सवाल उठा सके। तब अनुवाद व्यापक लोकलाइज़ेशन व्यवस्था के भीतर एक उत्पादन गतिविधि बन जाता है, न कि वह तंत्र जो पूरी व्यवस्था को परिभाषित करता है।
पेज मानचित्र बनाने से पहले लक्ष्य भाषा में इरादे पर शोध करें
कीवर्ड का अनुवाद इरादे का शोध नहीं है। शब्दकोश के हिसाब से समकक्ष वाक्यांश लक्षित बाज़ार में असामान्य, अत्यधिक औपचारिक, अस्पष्ट या ख़रीद प्रक्रिया के किसी दूसरे चरण में इस्तेमाल होने वाला हो सकता है। मूल भाषा की क्वेरी, खोज परिणामों के ढंग, ग्राहक सेवा की भाषा, प्रतिस्पर्धियों की शब्दावली और भीतरी बिक्री शब्दावली से शुरुआत करें। यह तय करने से पहले कि कौन-सा स्रोत पेज उत्तर देगा, शब्दों को कार्य के अनुसार समूहबद्ध करें: सीखना, तुलना करना, ढूँढ़ना, ख़रीदना, समस्या सुलझाना।
एक-से-एक URL समानता थोपें नहीं। यदि स्रोत बाज़ार में किसी ऐसी अवधारणा का पेज है जिसकी स्थानीय माँग कम है या जो स्थानीय उत्पाद उपलब्धता से टकराती है, तो उसका अनुवाद अनाथ पेज बना सकता है। इसके उलट, लक्षित बाज़ार को ऐसा पेज चाहिए हो सकता है जो स्रोत साइट पर है ही नहीं, क्योंकि कोई स्थानीय नियम, भुगतान विधि, श्रेणी शब्द या वितरण मॉडल एक अलग प्रश्न खड़ा करता है। जब उपयोगकर्ता की ज़रूरत असममित हो, तो लोकलाइज़ेशन असममितता की अनुमति देता है।
इरादा-मानचित्र को एक संपादकीय दस्तावेज़ की तरह दर्ज करें: लक्षित क्वेरी परिवार, उपयोगकर्ता कार्य, स्थानीय शब्दावली, पेज का ज़िम्मेदार व्यक्ति और सत्य का स्रोत। इससे अनुवादकों से यह अपेक्षा नहीं की जाती कि वे स्प्रेडशीट की एक कोठरी में उत्पाद रणनीति सुलझाएँ। इससे सर्च, कंटेंट और प्रोडक्ट टीमों को यह तय करने का साझा आधार भी मिलता है कि पेज का अनुवाद हो, अनुकूलन हो, नया बने या जानबूझकर छोड़ा जाए। यह ऐसा रिकॉर्ड भी बनाता है जिसे मूल भाषी समीक्षक उत्पादन शुरू होने से पहले चुनौती दे सकें, जब बाज़ार योजना बदलना तैयार साइट को दोबारा लिखने से सस्ता है।
URL संरचना फ़ैशन के लिए नहीं, संचालन के लिए चुनें
गूगल सलाह देता है कि अलग-अलग भाषा संस्करणों के लिए अलग URL इस्तेमाल किए जाएँ, न कि पेज की भाषा केवल ब्राउज़र सेटिंग या कुकी से बदली जाए। सामान्य संरचनाओं में देश-कोड डोमेन, सबडोमेन और सबडायरेक्टरी शामिल हैं, हर एक के अपने संचालन-संबंधी समझौते हैं। देश-कोड डोमेन मज़बूत भौगोलिक अलगाव देते हैं पर बुनियादी ढाँचे और शासन का बोझ बढ़ाते हैं। एक ही डोमेन पर सबडायरेक्टरी अक्सर सँभालने में आसान होती हैं। सही चुनाव खोज जितना ही बाज़ार की ज़िम्मेदारी, होस्टिंग, क़ानूनी अलगाव, तैनाती और एनालिटिक्स पर निर्भर करता है।
जब स्थिर और क्रॉल करने योग्य URL संरचना संभव हो, तब लोकेल के चुनाव को क्वेरी पैरामीटर में न छिपाएँ। हर स्थानीय पेज को स्थायी पता दें और रूटिंग को अनुमान योग्य रखें। यदि एक ही URL कभी फ़्रेंच और कभी अंग्रेज़ी दिखाता है, IP या सहेजी गई पसंद के आधार पर, तो उपयोगकर्ताओं और क्रॉलरों को असंगत सामग्री मिल सकती है। दिखने वाला भाषा या बाज़ार चयनकर्ता लोगों को किसी भी सुझाव को बदलने की सुविधा देना चाहिए।
अनुमानित स्थान या भाषा के आधार पर हर आगंतुक को अपने आप रीडायरेक्ट न करें। गूगल ऐसे स्वचालित रीडायरेक्ट के विरुद्ध सलाह देता है जो उपयोगकर्ताओं और सर्च इंजनों को सभी स्थानीय संस्करण देखने से रोकते हैं। जियोलोकेशन अपूर्ण है: यात्री, प्रवासी, बहुभाषी उपयोगकर्ता और कॉर्पोरेट नेटवर्क नियमित रूप से स्थान संबंधी अनुमानों को झुठलाते हैं। ज़बरदस्ती रास्ता तय करने से आमतौर पर एक सुझाव बैनर अधिक सुरक्षित है, बशर्ते चुना गया बाज़ार आसानी से बदला जा सके।
hreflang को सजावट नहीं, एक संबंध की तरह लागू करें
hreflang गूगल को किसी पेज के वैकल्पिक भाषा या क्षेत्रीय संस्करणों के बारे में बताता है। यह सामग्री का अनुवाद नहीं करता, सही व्यावसायिक ऑफ़र नहीं चुनता और असंगत URL नहीं सुधारता। हर संस्करण को स्वयं का और अपने प्रासंगिक विकल्पों का संदर्भ देना चाहिए, और संबंधों का पूरा समूह पारस्परिक होना चाहिए। गूगल इन एनोटेशन को HTML, HTTP हेडर या XML साइटमैप में लागू करने की सुविधा देता है; टीमों को अनावश्यक रूप से तर्क दोहराने के बजाय वही एक तरीका चुनना चाहिए जिसे वे भरोसे से सँभाल सकें।
भाषा और क्षेत्र कोड को इच्छित ऑडियंस दर्शाना चाहिए। जब एक ही स्थानीय पेज कई क्षेत्रों की सेवा करता हो तब केवल भाषा से लक्ष्य करें, और जब सार्थक भिन्नताएँ मौजूद हों, जैसे अलग उत्पाद या क़ानूनी शर्तें, तब भाषा के साथ क्षेत्र भी जोड़ें। जहाँ उपयुक्त हो वहाँ x-default संस्करण उन उपयोगकर्ताओं के लिए विकल्प दे सकता है जिनका मेल नहीं बैठता। देश कोड गढ़ें नहीं, और ऐसी सामग्री पर hreflang का लेबल न लगाएँ जो मूलतः किसी दूसरी भाषा में है।
जाँच तैनाती का हिस्सा है। टूटे हुए वापसी लिंक, कॉपी किए गए कैनोनिकल टैग, स्टेजिंग URL और अनुपस्थित विकल्प अक्सर टेम्पलेट बदलने के बाद उभरते हैं। hreflang का ग्राफ़ उसी स्रोत से बनाएँ जो जानता है कि कौन-से बाज़ार संस्करण मौजूद हैं, फिर नमूनों की स्वचालित जाँच करें। संपादकीय व्यवस्था को असममितता भी सँभालनी चाहिए: यदि कोई पेज जानबूझकर किसी बाज़ार में उपलब्ध नहीं है, तो एनोटेशन वास्तविकता दिखाएँ, न कि केवल मैट्रिक्स पूरा करने के लिए किसी सामान्य विकल्प की ओर इशारा करें।
पैसा, माप, फ़ॉर्म और उदाहरण स्थानीय बनाएँ
व्यावसायिक विवरण वही जगह है जहाँ केवल-अनुवाद वाले प्रोजेक्ट स्पष्ट रूप से विदेशी लगने लगते हैं। मुद्रा वही होनी चाहिए जिससे ग्राहक वास्तव में भुगतान कर सकें, और दिखाई गई कीमतों में कर, शिपिंग या क्षेत्रीय शर्तें व्यावसायिक मॉडल तथा लागू क़ानून के अनुसार स्पष्ट होनी चाहिए। संख्या विभाजक, तारीख़ें, इकाइयाँ, पते और टेलीफ़ोन प्रारूप स्थानीय अपेक्षाओं के अनुरूप हों। W3C का इंटरनेशनलाइज़ेशन मार्गदर्शन उपयोगी अंतरराष्ट्रीय सामग्री बनाने के हिस्से के रूप में स्थानीय प्रारूपों, नामों, पतों और सांस्कृतिक रूप से उपयुक्त उदाहरणों का विशेष उल्लेख करता है।
फ़ॉर्म को अपनी अलग डिज़ाइन समीक्षा चाहिए। पिन या पोस्टल कोड की लंबाई और बनावट अलग होती है; कुछ बाज़ारों में राज्य या प्रांत सामान्य रूप से इस्तेमाल होते हैं और कुछ में नहीं; व्यक्तियों के नाम किसी एक सार्वभौमिक पहला-नाम/अंतिम-नाम ढाँचे पर नहीं चलते; पते की पंक्तियाँ और फ़ोन की परंपराएँ बदलती रहती हैं। स्रोत बाज़ार के फ़ॉर्म पर अनुवादित लेबल लगा देने के बाद भी वह वैध स्थानीय डेटा अस्वीकार कर सकता है। मूल स्कीमा में फिट बैठने वाले काल्पनिक रिकॉर्ड के बजाय लक्षित बाज़ार के असली उदाहरणों से परीक्षण करें।
उदाहरण और प्रमाण भी सावधानी से यात्रा करने चाहिए। न्यूयॉर्क की कोई केस स्टडी किसी फ़्रांसीसी खरीदार के लिए प्रासंगिक रह सकती है यदि सीख सार्वभौमिक हो, पर विदेशी संस्थानों, कर संबंधी मान्यताओं और सांस्कृतिक संदर्भों से भरा पेज यह संकेत देता है कि वह बाज़ार बाद की सोच है। तय करें कि कौन-से उदाहरण अनुवादित हों, कौन-से स्थानीय उदाहरणों से बदले जाएँ, और कौन-से स्पष्ट रूप से अंतरराष्ट्रीय मामलों के रूप में पहचाने जाते रहें।
क़ानूनी पाठ को नियंत्रित स्थानीय सामग्री मानें
शर्तें, गोपनीयता सूचनाएँ, कुकी संबंधी जानकारी, वारंटी, वापसी नीति, सुलभता कथन और विनियमित उत्पाद दावे साधारण अनुवाद स्ट्रिंग नहीं हैं। इनमें अधिकार-क्षेत्र से जुड़े दायित्व हो सकते हैं, और जहाँ जोखिम इसकी माँग करे वहाँ इनके नामित क़ानूनी या अनुपालन ज़िम्मेदार होने चाहिए। कोई अनुवादक स्रोत पाठ को सही-सही उतार सकता है और फिर भी ऐसा क़ानूनी नियम बनाए रख सकता है जो लागू ही नहीं होता, या ऐसा नियम छोड़ सकता है जो लागू होता है। यह शासन की विफलता है, भाषा की त्रुटि नहीं।
कंटेंट मॉडल में क़ानूनी मॉड्यूल को मार्केटिंग पाठ से अलग रखें। अधिकार-क्षेत्र, प्रभावी तिथि, अनुमोदक और संस्करण दर्ज करें। जब कोई एक बाज़ार अपनी नीति बदले, तो अपडेट के लिए हर भाषा में आँख मूँदकर पाठ बदलना ज़रूरी नहीं होना चाहिए। जहाँ क़ानूनी सलाहकार या कोई अन्य योग्य पेशेवर चाहिए, वहाँ समीक्षा को रिलीज़ वर्कफ़्लो में शामिल करें और प्रतिस्पर्धियों की वेबसाइटों से क़ानूनी आवश्यकताएँ निकालने से बचें।
यही बात सहमति और डेटा संग्रह पर भी लागू होती है। कोई स्थानीय पेज डेटा को ऐसे सिस्टम की ओर भेज सकता है जहाँ प्रतिधारण, सहायता या सीमा-पार हस्तांतरण के निहितार्थ अलग हों। प्रोडक्ट, प्राइवेसी और इंजीनियरिंग टीमों को पता होना चाहिए कि बाज़ार संस्करण डेटा प्रवाह बदलता है या नहीं। यदि अंतर्निहित सेवा का व्यवहार क्षेत्र के अनुसार भिन्न है, तो अंतरराष्ट्रीय विस्तार को केवल फ़्रंट-एंड पाठ तक सीमित नहीं किया जा सकता।
हर बाज़ार को संपादकीय ज़िम्मेदार और सत्य का स्रोत दें
जब भिन्नता की ज़िम्मेदारी कोई नहीं लेता, तब लोकलाइज़ेशन क्षीण होने लगता है। उत्पादों के नाम बदलते हैं, स्क्रीनशॉट पुराने पड़ते हैं, कीमतें हिलती हैं और स्रोत भाषा के पेज दोबारा लिखे जाते हैं जबकि स्थानीय संस्करण जस के तस पड़े रहते हैं। ऐसा बाज़ार ज़िम्मेदार नियुक्त करें जो शब्दावली मंज़ूर कर सके, अपडेट को प्राथमिकता दे सके और तय कर सके कि स्थानीय सामग्री कब जानबूझकर अलग होनी चाहिए। उस व्यक्ति को हर वाक्य का अनुवाद नहीं करना है; उसे बाज़ार अनुभव पर अधिकार चाहिए।
स्वीकृत ब्रांड नामों, उत्पाद शब्दावली, तकनीकी शब्दों और ऐसे वाक्यांशों की एक टर्मबेस बनाए रखें जिनका अनुवाद नहीं होना चाहिए। जहाँ उपयुक्त हो वहाँ इसे ट्रांसलेशन मेमोरी के साथ जोड़ें, पर पुनरुपयोग को संदर्भ पर हावी न होने दें। एक ही स्रोत वाक्य को नेविगेशन लेबल, क़ानूनी सूचना और संपादकीय लेख में अलग-अलग शब्दों की ज़रूरत हो सकती है। स्वचालित एकरूपता तभी मूल्यवान है जब अंतर्निहित अवधारणा सचमुच एक ही हो।
बदलाव के प्रसार के नियम तय करें। सुरक्षा, कीमत और क़ानून से जुड़े महत्वपूर्ण अपडेट सभी बाज़ारों में एक साथ जारी करने पड़ सकते हैं। संपादकीय उदाहरण धीमी गति से अपडेट हो सकते हैं। नई सुविधाएँ केवल वहीं लॉन्च हों जहाँ उपलब्ध हों। कंटेंट-मैनेजमेंट वर्कफ़्लो को इन बदलावों को वर्गीकृत करना चाहिए ताकि स्थानीय टीमें जानें कि क्या हूबहू अनुवाद होना है, क्या अनुकूलित किया जा सकता है और किसके लिए नया स्थानीय निर्णय चाहिए। जब स्रोत साइट बार-बार प्रकाशित करती है तब प्रसार का स्पष्ट नियम और भी ज़रूरी हो जाता है, वरना अनुवाद की क़तारें उत्पाद के बहकाव का छिपा हुआ स्रोत बन जाती हैं।
स्थानीय बनाई गई यात्रा का आद्योपांत ऑडिट करें
गुणवत्ता जाँच स्थानीय पेज से पहले शुरू होनी चाहिए और कन्वर्ज़न के बाद तक चलनी चाहिए। लक्ष्य भाषा की क्वेरी खोजें, परिणाम का स्निपेट देखें, सही बाज़ार URL पर पहुँचें, लोकेल बदलें, गहराई में जाएँ, फ़ॉर्म भेजें, ईमेल पाएँ, भुगतान करें या कोटेशन माँगें, और सहायता लिंक जाँचें। अंतरराष्ट्रीय प्रोजेक्ट अक्सर सीमाओं पर टूटते हैं: अंग्रेज़ी में पुष्टि ईमेल, स्रोत बाज़ार का फ़ोन नंबर, स्थानीय स्तर पर अनुपलब्ध भुगतान विधि, या ऐसा लोकेल स्विच जो उपयोगकर्ता को होमपेज पर लौटा दे। इस परीक्षण में लेन-देन संबंधी ईमेल, डाउनलोड की गई फ़ाइलें और ग्राहक सहायता तक पहुँचने के चरण भी शामिल करें; सबसे कमज़ोर स्थानीय संपर्क-बिंदु अक्सर उसी पेज से ठीक आगे बैठा होता है जिसकी ज़िम्मेदारी कंटेंट टीम की है।
भाषा मेटाडेटा, कैनोनिकल URL, hreflang की पारस्परिकता, स्टेटस कोड, इंडेक्स करने योग्य टेक्स्ट और लोकेल-सजग साइटमैप के तकनीकी परीक्षण जोड़ें। फिर शब्दावली, कटे-फटे पाठ, सांस्कृतिक संदर्भ, तस्वीरों और व्यावसायिक सटीकता के लिए मानवीय समीक्षा जोड़ें। W3C दस्तावेज़ की भाषा घोषित करने और UTF-8 का उपयोग करने की सलाह देता है, पर तकनीकी शुद्धता केवल नींव है। कोई पेज हर मार्कअप जाँच पास कर सकता है और फिर भी आयातित लग सकता है तथा स्थानीय कार्य में विफल हो सकता है। समीक्षकों को दोषों को श्रेणी के अनुसार दर्ज करना चाहिए ताकि बार-बार आने वाली संरचना, अनुवाद और उत्पाद संबंधी समस्याएँ बाज़ार-दर-बाज़ार पैबंद लगाने के बजाय व्यवस्था के स्तर पर सुधारी जा सकें।
व्यावहारिक अंतर सीधा है: अनुवाद पूछता है कि क्या शब्द वही अर्थ लेकर चलते हैं; लोकलाइज़ेशन पूछता है कि क्या वेबसाइट दूसरे बाज़ार में वही व्यावसायिक वादा निभाती है। अंतरराष्ट्रीय खोज तब सफल होती है जब URL संरचना, भाषा संकेत, व्यावसायिक वास्तविकता और संपादकीय ज़िम्मेदारी उस वादे को मज़बूत करते हैं। जब इनमें से कोई एक परत ग़ायब हो, तो पूरी तरह सही अनुवादित वाक्य भी ऐसी यात्रा के भीतर बैठे रह जाते हैं जो विदेशी बनी रहती है।
व्यावहारिक चेकलिस्ट
- हर बाज़ार के लिए मूल भाषा में एक इरादा-मानचित्र बनाएँ।
- अंतरराष्ट्रीय URL संरचना चुनें और उसे दस्तावेज़ में दर्ज करें।
- तैनाती के समय hreflang संबंध और कैनोनिकल URL जाँचें।
- मुद्रा, पता, फ़ोन, तारीख़, इकाई और फ़ॉर्म व्यवहार को असली स्थानीय उदाहरणों से परखें।
- अधिकार-क्षेत्र से जुड़े पाठ की क़ानूनी और अनुपालन ज़िम्मेदारी सौंपें।
- हर लक्षित लोकेल में खोज से कन्वर्ज़न तक की पूरी यात्रा चलाकर देखें।
सवाल और जवाब
वेबसाइट अनुवाद और लोकलाइज़ेशन में मुख्य अंतर क्या है?
अनुवाद अर्थ बनाए रखते हुए सामग्री को एक भाषा से दूसरी भाषा में बदलता है। लोकलाइज़ेशन इससे आगे जाकर अनुभव को लक्षित बाज़ार के अनुरूप ढालता है, जिसमें खोज का इरादा, शब्दावली, मुद्रा, तारीख़ और संख्या के प्रारूप, फ़ॉर्म, पते, तस्वीरें, उदाहरण, उत्पाद उपलब्धता और क़ानूनी सामग्री शामिल हो सकती है। इसलिए स्थानीय बनाई गई साइट में ऐसे पेज हो सकते हैं जो नए लिखे गए, पुनर्गठित या छोड़ दिए गए हों, न कि स्रोत बाज़ार की वाक्य-दर-वाक्य नक़ल।
क्या हर अनुवादित पेज को hreflang चाहिए?
hreflang तब उपयोगी है जब साइट के पास वैकल्पिक भाषा या क्षेत्रीय संस्करण हों जिन्हें गूगल सर्च में एक-दूसरे से जोड़ा जाना चाहिए। किसी पेज को समझने योग्य बनाने के लिए यह आवश्यक नहीं है, और यह स्पष्ट URL या सही पेज भाषा की जगह नहीं लेता। जब इसका उपयोग हो, तो वैकल्पिक संबंध पारस्परिक और सटीक रूप से बनाए रखने चाहिए। टीमों को उन बाज़ार संस्करणों के लिए एनोटेशन बनाने से बचना चाहिए जो वास्तव में मौजूद नहीं हैं, या हर अनुपलब्ध लोकेल को किसी असंबद्ध सामान्य पेज की ओर भेजने से।
अंतरराष्ट्रीय साइटों को देश डोमेन चुनने चाहिए या सबडायरेक्टरी?
कोई एक संरचना हर संगठन पर फिट नहीं बैठती। देश-कोड डोमेन बाज़ारों का मज़बूत अलगाव देते हैं पर अधिक बुनियादी ढाँचा और शासन-व्यवस्था माँगते हैं। सबडायरेक्टरी साझा डोमेन पर तैनाती, अधिकार और एनालिटिक्स को सरल बना सकती हैं, जबकि सबडोमेन अलगाव का एक और मॉडल देते हैं। बाज़ार की ज़िम्मेदारी, क़ानूनी और संचालन आवश्यकताओं, प्लेटफ़ॉर्म की सीमाओं और दीर्घकालिक रखरखाव के आधार पर चुनें। जो भी मॉडल चुनें, स्थिर और क्रॉल करने योग्य URL रखें और उपयोगकर्ताओं को भाषा या बाज़ार बदलने का स्पष्ट रास्ता दें।