2011-12-27 10 views
6

सॉफ़्टवेयर अंतर्राष्ट्रीयकरण के समर्थन में, कई प्रोग्रामिंग भाषाएं और प्लेटफ़ॉर्म उपयोगकर्ता को दिखाए गए UI में उपयोग किए जाने वाले स्थानीय संसाधनों को प्राप्त करने के साधनों का समर्थन करते हैं (उदा। जावा की java.util.ResourceBundle कक्षा)। अक्सर, यदि उपयोगकर्ता के पसंदीदा लोकेल के लिए संसाधन उपलब्ध नहीं हैं, तो फ़ॉलबैक तंत्र या लोकेल रिज़ॉल्यूशन प्रक्रिया है, जो उपलब्ध संसाधनों के सेट से निकटतम मिलान संसाधनों का पता लगाने का प्रयास करेगी। उदाहरण के लिए, यदि en-US के लिए संसाधन उपलब्ध नहीं हैं, तो आमतौर पर सिस्टम en के लिए संसाधन ढूंढने का प्रयास करता है।क्या लोकेल रिज़ॉल्यूशन के लिए मानक एल्गोरिदम है?

लोकेल रिज़ॉल्यूशन प्रक्रिया लगभग कई भाषाओं और प्लेटफार्मों के संसाधन बंडल समाधानों के लिए लगभग समान दिखती है। क्या वे कुछ मानक लोकेल रिज़ॉल्यूशन एल्गोरिदम का पालन कर रहे हैं, या यदि नहीं, तो क्या ऐसा मानक मौजूद है?

+1

वे (i18n पेशेवर जो इस तरह की सुविधाओं को डिजाइन करते हैं) सर्वोत्तम प्रथाओं का पालन करते हैं। जब आप क्षेत्रों (~ देशों) और भाषाओं के बारे में कुछ जानते हैं तो सर्वोत्तम प्रथाएं कम या ज्यादा स्पष्ट होंगी। टॉम द्वारा वर्णित आसान गिरावट तंत्र 6 संस्करण तक जावा का हिस्सा था। अब जावा 7 और बीसीपी 47 के साथ और अधिक जटिल है - उदाहरण के लिए चीनी भाषाएं देखें (zh-sG और zh-CN => zh-hans, zh- TW, zh-HK, zh-MO => zh-hant)। Btw। ध्यान दें कि मैं भाषा टैग का उपयोग कर रहा हूं ... –

उत्तर

1

मुझे एक मानक प्रति से अवगत नहीं है।

हालांकि, उपयोग किए जाने वाले एल्गोरिदम इस तथ्य का एक छोटा सा परिणाम है कि स्थानीय श्रेणीबद्ध हैं। बिना किसी नाम के एक (पारंपरिक) रूट लोकेल है। इसके नीचे भाषा-केवल स्थानीय हैं (एन, एफआर, आदि)। उनके नीचे राष्ट्रीय लोकेशंस हैं (en_GB, en_US, आदि)। उन लोगों के नीचे, वैकल्पिक रूप से, वेरिएंट लोकेशंस (en_GB_Yorkshire, en_GB_cockney, आदि - यथार्थवादी उदाहरणों के लिए, नॉर्वे को देखें)।

उचित संसाधन खोजने का प्राकृतिक तरीका निम्नतम, सबसे विशिष्ट, लोकेल के साथ शुरू करना है, और जब तक आप कुछ नहीं पाते हैं तब तक पेड़ पर चलना है। तो, en_US_TX से शुरू करते हुए, आप en_US पर जाएं, फिर en, फिर रूट।

+0

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

+1

उस स्थिति में, सख्ती से पदानुक्रमित संकल्प के परिणामस्वरूप कुछ भी नहीं मिला। En_GB के लिए en_GB एक मैच नहीं है। आपके सुझाए गए किनारे दोनों मेरे लिए एक बुरा विचार प्रतीत होता है: आपको या तो लोकेल को ठीक से समर्थन देना चाहिए, या बिल्कुल नहीं। इसलिए उपयोगकर्ताओं को अपना लोकेल चुनने देना महत्वपूर्ण है: Ukrainians रूसी चुन सकते हैं यदि वह सबसे अच्छा हो सकता है, लेकिन इसे यूक्रेनी के लिए सर्वश्रेष्ठ फिट के रूप में नहीं रखा जाना चाहिए। –

+0

जेडीके 7 के लोकेल रिज़ॉल्यूशन कोड का पुन: उपयोग कैसे करें प्रश्न में एक लोकेल और कुछ मौजूदा ज्ञात लोकेशंस? – curious1

2

वहाँ जाहिरा तौर पर RFC 4647, की भाषा टैग है, जो की तुलना और मिलान के लिए एक उपयोगकर्ता की पसंदीदा भाषाओं की सूची निर्दिष्ट करने, साथ ही "फ़िल्टरिंग" और "देखने" तंत्र के लिए की "भाषा पर्वतमाला" वाक्य रचना का वर्णन मिलान है आरएफसी 4646 भाषा टैग के लिए भाषा-श्रेणियां। आरएफसी 4647 इन तंत्रों का वर्णन करता है:

फ़िल्टरिंग भाषा टैग के एक (संभावित खाली) सेट का उत्पादन करती है, जबकि लुकअप एक एकल भाषा टैग उत्पन्न करता है।

1

CLDR - Unicode Common Locale Data Repository एक प्रस्तावित (2015) के रूप में language distance के आधार पर एल्गोरिथ्म है। दूरी डेटा के बिना यह एक समाधान नहीं है, लेकिन भविष्य में समाधान के लिए देखने लायक है।

संबंधित मुद्दे