अनुवाद फ़ाइलों में प्रमुख मानों के लिए सर्वोत्तम अभ्यास

Question

सामान्य रूप से, अनुवाद विधियां एक कुंजी> मान मैपिंग लेती हैं और इसे किसी मान में बदलने के लिए कुंजी का उपयोग करती हैं। अब मैं आपकी अनुवाद कुंजी का नाम देने के लिए दो अलग-अलग तरीकों को पहचानता हूं और मेरी टीम के भीतर हम सर्वसम्मति से नहीं आते हैं जो सबसे अच्छा तरीका प्रतीत होता है।

विधि 1: पूर्ण अंग्रेजी शब्दों या वाक्यों उपयोग:

Name => Name 
Please enter your email address => Please enter your email address 

विधि 2: उपयोग कीवर्ड स्थिति का वर्णन:

NAME => Name 
ENTER_EMAIL => Please enter your email address 

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

क्या दोनों दुनिया या तीसरी विधि का सर्वोत्तम है? आप अपने आवेदन में अनुवाद कुंजी का उपयोग कैसे करते हैं? हमारे मामले में यह एक php- आधारित वेबप्लिकेशंस है, लेकिन मुझे लगता है कि ऊपर की समस्या सामान्य रूप से i18n के बारे में बात करने के लिए सामान्य है।

Answer 1

यह एक सवाल है जिसे आईओएस/ओएसएक्स डेवलपर्स का भी सामना करना पड़ता है। और उनके लिए एक standard tool called genstrings भी है जो विधि 1 मानता है। लेकिन निश्चित रूप से ऐप्पल डेवलपर्स को इस टूल का उपयोग करने की आवश्यकता नहीं है - मैं नहीं करता हूं।

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

विधि 2 का एक और लाभ यह है कि आप अंग्रेजी में और अपने सभी स्थानीयकरण में कुंजी को अपडेट करने के बारे में चिंता किए बिना अंग्रेजी टेक्स्ट बदल सकते हैं।

तो मैं विधि 2 की सिफारिश करता हूं!

Answer 2

क्यों दोनों दुनिया का उपयोग नहीं करते? मैं छोटी तारों के लिए विधि # 1 का उपयोग करता हूं, और लंबी स्ट्रिंग्स के लिए विधि # 2 जो पूर्ण वाक्य हैं। मैं एक ही फाइल में मिश्रण करने से डरता नहीं हूं।

उदाहरण के लिए, निम्न स्ट्रिंग में पाठ करता है, तो एक नए एप्लिकेशन संस्करण में उपयोगकर्ता अनुभव संशोधित किया गया है बदल सकता है:

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details."; 

तो यहाँ यह समझ में आता है विधि # 2 लागू करने के लिए।जब लोग बातें यह अक्सर मेरे लिए प्रतिबंधात्मक प्रकट होता है मानकीकृत करने के लिए कोशिश

"Preferences" = "Preferences"; 

सामान्य में: हालांकि, निम्न उदाहरण में की तरह साधारण तार के लिए, विधि # 1 अधिक उपयोगी है। व्यक्तिगत रूप से, मैं एक और "अराजकतावादी" दृष्टिकोण पसंद करता हूं जहां कई विधियां मान्य होती हैं (न केवल इस विधि # 1 बनाम विधि # 2 धागे में, बल्कि उदाहरण के लिए जब डेवलपर्स की एक टीम कोडिंग शैली से लड़ती है)।