भाषा का चयन केवल / पर करें, और /en/ तथा /fr/ जैसे स्पष्ट URL को हमेशा अपनी निर्दिष्ट भाषा में सामग्री देने दें। यह मार्गदर्शिका Mac डेस्कटॉप प्रकाशक को बताती है कि इस व्यवहार को कैसे निर्दिष्ट करें, खोजे जा सकने वाले दस्तावेज़ लिंक कैसे बनाए रखें और परिणाम का परीक्षण कैसे करें।

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

भाषा सेटिंग बदलने से पहले URL व्यवहार तय करें

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

अनुरोधित पथ अपेक्षित प्रतिक्रिया भाषा प्राथमिकता का प्रभाव
/ संक्षिप्त परिचय वाला भाषा चयनकर्ता परिचय और सुझाया गया लिंक बदल सकता है
/en/ पूरा अंग्रेज़ी दस्तावेज़ दस्तावेज़ की भाषा नहीं बदलती
/fr/ पूरा फ़्रेंच दस्तावेज़ दस्तावेज़ की भाषा नहीं बदलती
अप्रकाशित पथ पृष्ठ नहीं मिलने की प्रतिक्रिया चुपचाप किसी दूसरे दस्तावेज़ में नहीं बदलना चाहिए

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

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

हर पृष्ठ पर दोनों भाषा लिंक दिखाई देते रहें। मूल पृष्ठ पर सुझाई गई भाषा पहला चुनाव आसान बना सकती है, लेकिन दूसरे विकल्प को छिपाए बिना। पूरे दस्तावेज़ों पर भाषा बदलने वाला लिंक सीधे समकक्ष दस्तावेज़ पर ले जाना चाहिए।

मूल पृष्ठ की भाषा के लिए पूर्वानुमेय नीति चुनें

Accept-Language पसंदीदा प्रतिक्रिया भाषाएँ और fr;q=0.9,en;q=0.5 जैसे गुणवत्ता भार व्यक्त करता है। इससे सर्वर के लिए अनुरोधित हर भाषा उपलब्ध कराना अनिवार्य नहीं होता। शून्य गुणवत्ता मान का अर्थ है कि भाषा स्वीकार्य नहीं है। Content-Language लौटाए गए प्रतिनिधित्व के लक्षित पाठकों का वर्णन करता है; यह कोई रूट नहीं चुनता। RFC 9110: HTTP Semantics, अनुभाग 8.5, 12.4.2 और 12.5.4।

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

स्पष्ट नीति वाला भाषा-मिलान कार्यान्वयन इस्तेमाल करें। RFC 4647 फ़िल्टरिंग और लुकअप में अंतर बताता है: लुकअप एक परिणाम चुनता है, अनुरोधित रेंज को उनकी प्राथमिकता के क्रम में देखता है और मेल खोजते समय धीरे-धीरे उपटैग हटाता है। इसके अनुसार, लुकअप इस्तेमाल करने वाले अनुप्रयोगों को अपना डिफ़ॉल्ट व्यवहार तय करना होगा। इसलिए fr-CA का अनुरोध लुकअप के ज़रिए समर्थित सामान्य fr परिचय तक पहुँच सकता है। RFC 4647: Matching of Language Tags, अनुभाग 3.4–3.4.1।

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

मूल पृष्ठ के अनुरोध की प्राथमिकता इस उदाहरण में अपेक्षित परिणाम
हेडर अनुपस्थित दोनों विकल्पों वाला अंग्रेज़ी परिचय
fr दोनों विकल्पों वाला फ़्रेंच परिचय
fr-CA,fr;q=0.9,en;q=0.5 फ़्रेंच परिचय
en;q=0.9,fr;q=0.2 अंग्रेज़ी परिचय
de फ़ॉलबैक चयनकर्ता
fr;q=0,en;q=1 अंग्रेज़ी परिचय; फ़्रेंच नहीं चुनी जाती
*;q=0 बेमेल भाषा के लिए स्पष्ट रूप से तय व्यवहार

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

दस्तावेज़ की भाषा, लिंक और खोज एनोटेशन को एकसमान रखें

हर HTML दस्तावेज़ के लिए lang एट्रिब्यूट में उसकी वास्तविक मुख्य भाषा सेट करें: अंग्रेज़ी पृष्ठ के लिए en और फ़्रेंच पृष्ठ के लिए fr। WHATWG lang को किसी एलिमेंट की सामग्री और पाठ वाले एट्रिब्यूट की मुख्य भाषा के रूप में परिभाषित करता है; इसे छोड़ने पर भाषा पैरेंट से प्राप्त होती है। केवल भाषा उपसर्ग से यह घोषणा नहीं होती। HTML Standard: The lang and xml:lang attributes।

पृष्ठ के पाठ के साथ नेविगेशन लिंक भी जाँचें। WHATWG URL Standard के अनुसार, रिलेटिव URL एक बेस URL के सापेक्ष हल होते हैं। उदाहरण के लिए, अलग दस्तावेज़ बेस न होने पर, https://example.com/en/ से fr/ का पता https://example.com/en/fr/ बनता है; /fr/ उसी ओरिजिन के फ़्रेंच पथ पर जाता है। दिखाई देने वाले भाषा स्विचर में इच्छित पूर्ण पथ इस्तेमाल करें। URL Standard: URL writing and parsing।

खोज एनोटेशन का उद्देश्य अलग है। Google समकक्ष भाषा एनोटेशन को HTML, HTTP हेडर या साइटमैप के ज़रिए समर्थित करता है। ऐसा तरीका चुनें जिसका प्रबंधन आसान हो। हर संस्करण को पूरी तरह योग्य URL के साथ अपना और अपने समकक्षों का उल्लेख करना चाहिए, और एनोटेशन के ज़रिए संस्करणों को एक-दूसरे से लिंक करना चाहिए। मूल चयनकर्ता x-default गंतव्य हो सकता है। Google को अपने पृष्ठ के स्थानीयकृत संस्करणों के बारे में बताएँ।

काल्पनिक संग्रह के लिए एनोटेशन मैपिंग यह है:

एनोटेशन काल्पनिक गंतव्य
en https://example.com/en/
fr https://example.com/fr/
x-default https://example.com/

इन संबंधों को प्रकाशन प्रणाली के समर्थित एनोटेशन तरीके से दर्ज करें। यह मैपिंग एक विनिर्देश है, चलने वाला मार्कअप नहीं। x-default सर्वर नेगोशिएशन कॉन्फ़िगर नहीं करता और न ही अनुवाद देता है। Google यह भी कहता है कि वह पृष्ठ की भाषा का निर्धारण एल्गोरिदम से करता है, hreflang या HTML lang से उसका पता नहीं लगाता। Google को अपने पृष्ठ के स्थानीयकृत संस्करणों के बारे में बताएँ।

पूरे अनुवादों को मूल पृष्ठ के अनुकूलन से स्वतंत्र रूप से उपलब्ध रखें। Google के दस्तावेज़ बताते हैं कि उसका क्रॉलर Accept-Language के बिना अनुरोध भेजता है और चेतावनी देते हैं कि स्थान के अनुसार ढलने वाले पृष्ठों के कुछ रूप शायद खोजे न जा सकें। भरोसेमंद फ़ॉलबैक और सीधे भाषा URL इस खोज समस्या को हल करते हैं, बिना क्रॉलर से मूल पृष्ठ के अलग-अलग परिचय माँगवाए। Google स्थान के अनुसार ढलने वाले पृष्ठों को कैसे क्रॉल करता है।

कैश किए गए मूल पृष्ठों की प्रतिक्रियाओं में भाषा चुनाव का ध्यान रखें

जब मूल पृष्ठ का चयन Accept-Language पर निर्भर हो, तो फ़ॉलबैक समेत मूल पृष्ठ की प्रतिक्रियाओं में Vary: Accept-Language शामिल करें। मौजूद अन्य परिवर्तन फ़ील्ड बनाए रखें। फ़्रेंच मूल पृष्ठ की एक उदाहरणात्मक प्रतिक्रिया में नीचे दिया गया हेडर अंश शामिल होगा; यह पूरा HTTP संदेश नहीं है: RFC 9110: HTTP Semantics, अनुभाग 12.5.5।

Content-Type: text/html; charset=utf-8
Content-Language: fr
Vary: Accept-Language

RFC 9111 के अनुसार, किसी संग्रहीत प्रतिक्रिया को बिना दोबारा सत्यापन के इस्तेमाल करने से पहले कैश को Vary में नामित अनुरोध फ़ील्ड मिलाने होंगे। यह इसलिए महत्वपूर्ण है कि मूल URL वही रहता है, जबकि उसका परिचय बदलता है। Vary चयन के इनपुट बताता है; यह भाषा मिलान लागू नहीं करता। RFC 9111: HTTP Caching, अनुभाग 4.1।

इस डिज़ाइन में /en/ और /fr/ के दस्तावेज़ Accept-Language के आधार पर नहीं बदलते। रूटिंग अनुबंध के अनुसार पूरे डिलीवरी पथ, साझा कैश सहित, की जाँच करें। व्यावहारिक जाँच के तौर पर मूल पृष्ठ के लिए बारी-बारी से अंग्रेज़ी और फ़्रेंच अनुरोध भेजें, फिर उनका क्रम उलट दें। यदि मूल पृष्ठ बार-बार पहले अनुरोध की गई भाषा लौटाता है, तो रूटिंग और कैश व्यवहार की एक साथ जाँच करें।

Mac से अनुबंध का परीक्षण करें

पहले किसी सार्वजनिक प्रदर्शन ओरिजिन पर तीन काल्पनिक पृष्ठ तैयार करें। नीचे दिए परीक्षण के लिए ज़रूरी है कि उस ओरिजिन में केवल /, /en/ और /fr/ पर प्रदर्शन संग्रह मौजूद हो। यह पृष्ठ नहीं बनाता और न ही होस्ट कॉन्फ़िगर करता है। ऊपर दिए उदाहरणात्मक example.com पते काम करने वाली परीक्षण व्यवस्था नहीं हैं।

Mac पर Terminal ऐप खोलें और curl --version चलाकर पुष्टि करें कि curl उपलब्ध है। फिर नीचे दिया पूरा शेल डायग्नोस्टिक पेस्ट करें। संकेत मिलने पर प्रदर्शन ओरिजिन दर्ज करें, जिसमें https:// शामिल हो, लेकिन कोई पथ या अंत में स्लैश न हो।

printf 'Public demo origin, without a trailing slash: '
IFS= read -r demo_origin
case "$demo_origin" in
  https://*) ;;
  *) printf 'Enter an HTTPS origin.\n' >&2; exit 1 ;;
esac

for demo_path in / /en/ /fr/; do
  for demo_language in '' 'en' 'fr' 'fr-CA,fr;q=0.9,en;q=0.5' 'en;q=0.9,fr;q=0.2' 'de' 'fr;q=0,en;q=1'; do
    printf '\nPath: %s | Accept-Language: %s\n' \
      "$demo_path" "${demo_language:-absent}"
    curl --silent --show-error --connect-timeout 5 --max-time 15 \
      --dump-header - --header "Accept-Language: $demo_language" \
      "$demo_origin$demo_path" || exit 1
  done
done

यह डायग्नोस्टिक प्रतिक्रिया हेडर और बॉडी प्रिंट करता है। --header curl को प्राथमिकता देता है; खाली मान से वह हेडर हट जाता है। --dump-header - हेडर को मानक आउटपुट पर प्रिंट करता है, और समय सीमाएँ हर ट्रांसफ़र की अवधि सीमित रखती हैं। रीडायरेक्ट का अनुसरण जानबूझकर शामिल नहीं है, ताकि अनपेक्षित रीडायरेक्ट दिखाई दे। curl — How To Use।

स्क्रिप्ट का शेल सिंटैक्स जाँचा गया है; यहाँ किसी प्रदर्शन परिनियोजन या वास्तविक भाषा रूटिंग के परिणाम का दावा नहीं किया गया है। curl ट्रांसफ़र विफल होने पर यह रुक जाती है, लेकिन HTTP त्रुटि प्रतिक्रिया फिर भी आउटपुट में आ सकती है और उसकी जाँच करनी होगी।

मूल पृष्ठ की प्रतिक्रियाओं की तुलना प्राथमिकता तालिका से करें। फिर हर /en/ प्रतिक्रिया में अंग्रेज़ी सामग्री और हर /fr/ प्रतिक्रिया में फ़्रेंच सामग्री जाँचें, चाहे दी गई प्राथमिकता कुछ भी हो। स्टेटस कोड, अनपेक्षित Location फ़ील्ड, लौटाई गई भाषा घोषणा और वास्तविक दस्तावेज़ पाठ जाँचें। सही हेडर के साथ गलत बॉडी भी विफल परिणाम है।

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

नेगोशिएशन उपलब्ध न हो तो स्थिर चयनकर्ता इस्तेमाल करें

इस डिज़ाइन के लिए ऐसी डिलीवरी परत चाहिए जो अनुरोध हेडर पढ़कर प्रतिक्रिया चुन सके। WHATWG के दस्तावेज़ भाषा और URL तंत्र दस्तावेज़ों तथा पतों का वर्णन करते हैं; lang एट्रिब्यूट जोड़ने या लिंक का पाठ बदलने से अपने-आप HTTP नेगोशिएशन नहीं होता। अनुरोध पर निर्भर चयन HTTP डिलीवरी कॉन्फ़िगरेशन में होना चाहिए। HTML Standard, RFC 9110: HTTP Semantics।

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

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

स्रोत