2009-03-07 18 views
16

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

कहें कि आपके पास कई स्क्रीनों में एक संपादन बटन है (एक उपयोगकर्ता को संपादित करने के लिए, एक समूह को संपादित करने के लिए एक)। आप निम्न कुंजी का उपयोग कर सकते हैं:

  • editUserButton.label = उपयोगकर्ता संपादित करें ...
  • editGroupButton.label = समूह संपादित करें ...

या

  • editUser = संपादित करें उपयोगकर्ता ...
  • संपादित समूह = समूह संपादित करें ...

या

  • user.edit = उपयोगकर्ता संपादित करें ...
  • group.edit = संपादित करें समूह ...

क्या योजना आप पसंद करते हैं और क्यों?

उत्तर

12

मैं अपने अक्षरों को प्रयोग या क्रिया वर्ग नाम से उपसर्ग करता हूं। उदाहरण के लिए:

PlaceOrder.invalidId=Invalid id for order {0} 
PlaceOrder.success=Your order {0} was successful 
PlaceOrder.fail.visa=Your visa was ... 
PlaceOrder.fail.communications=We could not... 
PlaceOrder.submit=Buy now 

Login=Login 
Login.fail=Your credentials did not... 
Login.alread=You are already logged in

इस तरह आप टकराव से बचने:

EditStudent=Edit 
EditClass=Edit 
EditCourse=Edit Course

... और यह भी कि तुम क्या आसान की जरूरत है पा सकते हैं।

एक और तरीका है मैं समूह इकाई के द्वारा होता है:

Person.id=# 
Person.name=First name 
Person.surname=Surname

इन संस्थाओं के साथ टेबल पर हेडर के रूप में प्रकट कर सकते हैं। यह आपको इस तरह के मामलों में बचाता है:

Person.id=# 
Class.id=# 
Course.id=Course Id

अंततः संपत्ति कुंजी में संदर्भ प्रदान करके आप स्वयं को झूठे अनुवादों से बचा सकते हैं। उदाहरण के लिए मैं एक बार था:

no=no

जो ऊपरी बाएँ कक्ष पर एक आईडी (#) तालिका हेडर के रूप में इस्तेमाल किया जा रहा था, लेकिन हमारे फ्रेंच अनुवादक फ्रेंच के लिए ऐसा किया:

no=non

... उसने सोचा कि यह शब्द "नहीं" (हाँ का नकारात्मक) था। :)

क्लासनाम के साथ उपसर्ग करना अंतिम (लेकिन कम से कम नहीं) कक्षाओं को दोबारा बदलना/नाम बदलना और टेम्पलेट्स को देखने के बिना इन संपत्ति कुंजियों को तुरंत अपडेट करना चाहते हैं।

+0

मैंने कभी भी उपयोग के मामले में बेसिंग कुंजी के बारे में सोचा नहीं। एक उचित दृष्टिकोण की तरह लगता है। +1 –

+0

यह 100+ उपयोगकेस, विचारों और कार्यों के साथ एक एप्लिकेशन प्राप्त करने में सहायता करता है। मैंने अधिक जानकारी के साथ अपना उत्तर भी अपडेट किया है। – cherouvim

-1

मुझे लगता है कि पहली जगह में आपको उस तरह के डेटा को स्टोर करने के लिए किसी प्रकार की एक्सएमएल फाइलों का उपयोग करना चाहिए।

कुछ की तरह:

< एक्सएमएल संस्करण = "1.0" एन्कोडिंग = "utf-8" स्टैंडअलोन = "हाँ"? >
< एक्सएमएल >
        < बटन >
                < संपादित >
                        < उपयोगकर्ता > *** उपयोगकर्ता संपादित करें *
</उपयोगकर्ता >
                        < समूह > संपादित करें समूह </समूह >
                </संपादन >
        </बटन >
</xml > **

और फिर एक "का अनुवाद" वर्ग का उपयोग पाने के लिए (और सेट/बचाने के लिए) ये पाठ।

कुछ की तरह:

myTranslateClass.load ('translate.xml');
myTranslateClass.get ('बटन', 'संपादित करें', 'उपयोगकर्ता');

यह एक साधारण उदाहरण है।

+0

गुण फ़ाइलें मेरे मामले में अधिक सुविधाजनक हैं क्योंकि हम जावा और फ्लेक्स का उपयोग कर रहे हैं। –

+0

इस तरह के भंडारण के लिए एक गैर-सख्त संरचित फाइलों का उपयोग करना एक अच्छा विचार नहीं है (मेरी राय में), क्योंकि संग्रहित डेटा में खुद को खोना थोड़ा आसान है और इसके अलावा कई विरोधाभासी समस्याएं हैं। इसके अलावा, एक्सएमएल या जेएसओएन सभी भाषाओं द्वारा संभाला जाता है, जो आपको अधिक लचीलापन देता है:] –

0

हम इसे इस शब्द के अंग्रेजी संस्करण पर आधारित करते हैं। पूर्व: EditUser यह हमारे डेवलपर्स द्वारा आसानी से पठनीय किया जा सकता था और कई स्थानों पर पुन: उपयोग किया जा सकता है, जो कि पूरे ऐप में आवश्यक है।

0

इसे अंग्रेजी पाठ पर आधारित करें, लेकिन विंडो/संवाद/के साथ उपसर्ग/जिसमें आप शब्द या वाक्यांश प्रकट होते हैं। कम से कम जब लेआउट स्पेस सीमित है, तो आप हर जगह एक ही स्ट्रिंग रखने के जाल में गिरने से बचना चाह सकते हैं: यह आपको सभ्य लेआउट पाने के लिए संक्षिप्त रूप से रोकता है, खासकर फिनिश जैसे पोलिसीलेबिक भाषाओं में।

बेशक, आपको अभी भी सामान नामकरण में लगातार बने रहने का प्रयास करना चाहिए। यदि आप इसे वाणिज्यिक रूप से कर रहे हैं तो तारों की संख्या में वृद्धि से अनुवाद लागत भी बढ़ेगी।

और समानार्थी शब्दों के खतरे को अनदेखा न करें। संदर्भ प्रदान करने से उसे रोकने में मदद मिलती है। डरो मत, वास्तविक अंग्रेजी शब्द से संसाधन का नाम लंबा बनाओ, इससे अनुवादकों को काफी मदद मिल सकती है।

0

@ चेरौविम के उत्तर के लिए +1, लेकिन यह हमेशा दस्तावेज़ीकरण के लिए आता है।

स्ट्रिंग स्वरूपणीय होने पर प्रत्येक पैरामीटर के डेटा प्रकार सहित संसाधन मान फ़ाइल प्रारूप द्वारा जो भी टिप्पणी तंत्र का समर्थन किया जाता है, उसका उपयोग करें। उदाहरण के लिए, .resx प्रारूप के लिए वीएस संपादक एक टिप्पणी फ़ील्ड का खुलासा करता है जो इसे बहुत आसान बनाता है।

तो जैसे संदेश:

{0} से पहले काम शेड्यूल करने में असमर्थ {1}।

लॉग इन त्रुटि संदेश, {0}:: नौकरी के नाम, {1} दिनांक/आईएसओ 8601 प्रारूप में समय

की तरह कुछ के रूप में दस्तावेज की जाएगी।

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