हम अपनी वेबसाइट पर बहु-भाषा सबसाइट बना रहे हैं।
मैं 2-अक्षर भाषा कोड का उपयोग करना चाहूंगा। स्पेनिश और फ्रेंच आसान हैं। उन्हें URL मिलेंगे जैसे:
mydomain.com/es
mydomain.com/fr
लेकिन मैं पारंपरिक और सरलीकृत चीनी के साथ एक समस्या में भाग रहा हूं। क्या ऐसे मानक हैं जिनके लिए इन भाषाओं के लिए 2 अक्षर कोड का उपयोग करना है?
mydomain.com/zh
mydomain.com/?
जवाबों:
@dkarp एक उत्कृष्ट सामान्य उत्तर देता है। मैं चीनी के बारे में कुछ अतिरिक्त बारीकियों को जोड़ूंगा:
ऐसे कई देश हैं जहाँ चीनी मुख्य लिखित भाषा है। उनके बीच मुख्य अंतर यह है कि वे सरलीकृत या पारंपरिक पात्रों का उपयोग करते हैं, लेकिन इसमें मामूली क्षेत्रीय अंतर (शब्दावली, आदि) भी हैं। इनमें अंतर करने का मानक तरीका एक देश कोड के साथ होगा, जैसे zh_CNकि मुख्य भूमि चीन के लिए, zh_SGसिंगापुर के लिए, zh_TWताइवान के लिए, या zh_HKहांगकांग के लिए।
मुख्यभूमि चीन और सिंगापुर दोनों ही सरलीकृत पात्रों का उपयोग करते हैं, और अन्य पारंपरिक पात्रों का उपयोग करते हैं। चूंकि चीन और ताइवान दो सबसे बड़ी आबादी वाले हैं, बस zh_CNऔर zh_TWअक्सर एक वेबसाइट के सरलीकृत और पारंपरिक चरित्र संस्करणों को भेद करने के लिए उपयोग किया जाता है।
अधिक तकनीकी रूप से सही, लेकिन आमतौर पर व्यवहार में उपयोग नहीं किया जाता है , हालांकि, विभिन्न देशों को अलग करने के लिए सार्थक मामलों के अलावा, चीनी पात्रों के zh_HANSलिए (सामान्य) सरलीकृत चीनी अक्षरों और zh_HANTपारंपरिक चीनी पात्रों के लिए उपयोग किया जाएगा ।
zh_HANS) और वास्तव में सामान्य उपयोग में क्या है ( zh_CN)। आप दो शब्दों के लिए Google खोज कर सकते हैं - यह लगभग 7 से 1 अंतर के पक्ष में है zh_CN, जो ईमानदारी से मेरी अपेक्षा से कम है।
inurl:zh_CN4.3M हिट देता है; inurl:zh_HANS20K देता है। फिर भी, वास्तव में सूचनात्मक उत्तर।
इसके लिए वास्तव में एक मानक प्रतिनिधित्व है। जैसा कि लोगों ने ठीक उसी समस्या में भाग लिया है जिसे आप देख रहे हैं - एक ही भाषा, लेकिन विभिन्न बोलियाँ या वर्ण - उन्होंने दो-अक्षर भाषा कोड को दो-अक्षर वाले क्षेत्र कोड के साथ बढ़ाया है। तो आपके पास एक सार्वभौमिक फ्रेंच पेज हो सकता है mydomain.com/fr, लेकिन फ्रांसीसी कनाडाई पाठकों के लिए अंतर्राष्ट्रीयकरण आपको mydomain.com/fr_CA(कनाडा) और mydomain.com/fr_FR(फ्रांस) के साथ छोड़ सकता है । कुछ प्लेटफ़ॉर्म भाषा और क्षेत्र कोड (इसलिए fr-CAऔर fr-FR) को अलग करने के लिए अंडरस्कोर के बजाय डैश का उपयोग करते हैं ।
सरलीकृत चीनी के लिए मानक स्थान है zh_CN। पारंपरिक चीनी के लिए मानक स्थान है zh_TW।
मैं आपको वास्तविक बीसीपी 47 मानकों के दस्तावेजों की ओर इशारा करने में संकोच करता हूं , क्योंकि वे उह, विस्तार पर थोड़ा भारी और पठनीयता पर थोड़ा प्रकाश डालते हैं। बस मानक स्थानीय पहचानकर्ताओं के साथ जाएं, जैसे जावा द्वारा उपयोग किए गए हैं , और आप ठीक हो जाएंगे।
भाषा उस पर निर्भर है जहाँ उसे बोला जाता है (दोह!), इसलिए भाषा और स्थानीय कोड उस वास्तविकता को दर्शाते हैं। zhमूल भाषा कोड है, लेकिन क्योंकि इसके दो प्रमुख रूप हैं, वहाँ हैं zh_Hansऔरzh_Hant , लेकिन वे अभी भी केवल भाषा कोड हैं, स्थान नहीं।
स्थान-विशेष
किसी विशेष स्थान में किस भाषा का उपयोग किया जाता है, इसे पूरी तरह से निर्दिष्ट करने के लिए , देश कोड को अभी भी प्रत्यय देना है, इसलिए बनाना zh_Hans_HKऔरzh_Hant_HK हांगकांग में बोली जाने वाली क्रमशः सरलीकृत और पारंपरिक चीनी लिए।
वास्तव में, वास्तविकता यह है कि कई देशों में देश कोड की तुलना में कुछ अधिक विशिष्ट है, लेकिन यह बहुत तेजी से सीएलडीआर जैसे डेटाबेस की जटिलता और रखरखाव को बढ़ाने की संभावना है, साथ ही इसमें फीड करने के लिए समर्थन बुनियादी ढाँचा, जैसे आईपी से स्थान विवरण निष्कर्षण , आम तौर पर उपलब्ध या पर्याप्त पर्याप्त नहीं है।
निश्चित पाठ
अब, यदि कोड केवल यह निर्दिष्ट करने के लिए है कि उपयोगकर्ता इंटरफ़ेस में उपयोग करने के लिए निश्चित स्ट्रिंग्स का कौन सा सेट, या यहां तक कि पूरे पृष्ठ किसी साइट पर सेट होते हैं, तो देश प्रत्यय वास्तव में आवश्यक नहीं है, जब तक कि कुछ स्थानों पर जहां भाषा बदलती है पर्याप्त रूप से पर्याप्त (स्थान-आधारित जानकारी) एक पूरे अलग संसाधन सेट बनाने के लिए परेशान करने के लिए।
संसाधन जितना बड़ा होगा, उतनी ही अधिक संभावना होगी कि इस संदर्भ में भाषा कोड [इस संदर्भ में, केवल एक भाषा विशेषता है, बजाय एक सच्चे लोकेल के, इसलिए आप इसे वही कह सकते हैं जो आपको पसंद है!] आवश्यक होगा, लेकिन कम से कम आप केवल तभी करना है जब आवश्यक हो।
ऑन-द-फ्लाई मान
हालाँकि, यदि दिनांक, समय, मुद्राओं और संख्याओं, जैसे-पर-फ़्लाई, जैसे स्थानीय चर मानों को प्रारूपित करना चाहते हैं, तो स्थान महत्वपूर्ण हो जाते हैं, क्योंकि ऐसे सभी उपकरण जो इस तरह की कार्यक्षमता का समर्थन करते हैं (जैसे यूनिकोड सीएलडीआर डेटा पर आधारित) उनसे उम्मीद करते हैं। जब तक आप हर घर के लिए संसाधन सेट नहीं बनाना चाहते, तब तक कोड के लिए अलग-अलग सेटिंग होना चाहिए , जिसके लिए इन-हाउस-जनरेटेड UI भाषा का उपयोग करने के लिए सेट किया जाना चाहिए ज्ञात लोकेल के , और उन्हें विज्ञापन nauseum बनाए रखना है!
ब्राउज़र भाषा उपकरण
ध्यान दें कि जब इनपुट के रूप में संपादित किए जा सकने वाले वेब पेज के लिए लोकेल निर्दिष्ट किया जा सकता है, और क्षेत्र के लिए विशेषताओं या सीएसएस में वर्तनी जांच को सक्षम किया गया है, तो ब्राउज़र के भाषा उपकरण उस लोकेल के अनुसार क्षेत्र को वर्तनी जाँचेंगे।
मानदंड
आपको यह स्पष्ट करना होगा कि संसाधन सेट क्या प्रदान कर रहा है, इसलिए विचार करें:
रखरखाव ओवरहेड को कम करने के लिए स्प्रेडशीट
मैं UI स्ट्रिंग्स को रखने के लिए एक स्प्रेडशीट का उपयोग करता हूं, जहां प्रत्येक भाषा कोड में एक पैरेंट कोड होता है, ताकि उसके स्ट्रिंग के संस्करण के लिए सेल में एक सूत्र हो, जो अभिभावक से उसका स्ट्रिंग प्राप्त करता है। उस भाषा और स्ट्रिंग के लिए एक कस्टम स्ट्रिंग बनाने के लिए, मैं सिर्फ सटीक पाठ के साथ सेल सूत्र को अधिलेखित करता हूं। यह संसाधन रखरखाव की मात्रा को कम करता है। मैं अंत में एक मैक्रो चलाता हूं जो प्रत्येक भाषा के लिए एक पूर्ण संसाधन फ़ाइल बनाता है।