स्थानीयकरण स्ट्रिंग संसाधनों को कैसे व्यवस्थित करें?


14

हम एक बड़े एप्लिकेशन को विकसित कर रहे हैं, जिसमें कई छोटे पैकेज शामिल हैं। प्रत्येक पैकेज में स्थानीयकरण के लिए संसाधन फ़ाइलों का अपना सेट होता है।

स्थानीयकरण तार को व्यवस्थित और नाम देने के लिए सबसे अच्छा तरीका क्या है?

यहाँ मेरे विचार अब तक हैं:

डुप्लिकेट को संभालना

एक ही पैकेज में एक ही पाठ (कहते हैं, "ज़िप कोड") कई बार हो सकता है। प्रोग्रामिंग इंस्टिंक्ट (DRY) मुझे सभी घटनाओं द्वारा साझा एक एकल स्ट्रिंग संसाधन बनाने के लिए कहता है ।

फिर, एक अनुवादक कुछ स्थानों पर एक लंबा अनुवाद ("पोस्टलेइट्ज़हल") और कम जगह वाले स्थानों में एक छोटा ("PLZ") चुनना चाह सकता है। या हम कुछ घटनाओं ("ज़िप कोड:") में एक बृहदान्त्र को जोड़ने का फैसला कर सकते हैं, लेकिन दूसरों को नहीं। या हमें कुछ स्थानों पर एक अलग पूंजीकरण ("ज़िप कोड") की आवश्यकता हो सकती है। ये सभी तर्क प्रति उपयोग एक संसाधन बनाने की ओर इशारा करते हैं , भले ही उनकी सामग्री समान हो

नामकरण

यदि हम डुप्लिकेट को समाप्त करने का लक्ष्य रखते हैं, तो यह सामग्री के नाम संसाधनों को समझ में आता है , हो सकता है कि उपसर्ग के माध्यम से उपयोग के प्रकार पर इशारा कर रहा हो। तो हमारे पास labelOK= "ठीक" हो सकता है , messageFileTooLarge= "फ़ाइल अधिकतम फ़ाइल आकार से अधिक है।" , और labelZipCode= "ज़िप कोड"

सामग्री द्वारा नामकरण का स्वाभाविक रूप से स्वरूप तर्कों को संभालने का लाभ है: संसाधन messageFileHas_0_MBWhileMaximumIs_1_MBस्पष्ट रूप से दो स्वरूपण तर्क, वास्तविक फ़ाइल आकार और अधिकतम फ़ाइल आकार लेता है।

यदि हम डुप्लिकेट की अनुमति देते हैं, हालांकि, अकेले सामग्री द्वारा नामकरण करने का कोई मतलब नहीं है। अद्वितीय संसाधन नाम प्राप्त करने के लिए, हमें किसी तरह संसाधन नाम के उपयोग को शामिल करना होगा । यह ग्राफिकल नियंत्रण के लिए काम करता है, हालांकि पहचानकर्ता थोड़ा लंबा हो जाते हैं: fileSelectionConfirmationButtonText= "ओके" , customerDetailsTableColumnZipCode= "ज़िप कोड" । हालांकि, गैर-दृश्य कोड फ़ाइलों के लिए, यह कठिन हो जाता है। यदि आप यह नहीं जानते कि स्ट्रिंग का एक विशिष्ट उपयोग कैसे किया जाता है, तो यह पता नहीं चलता है कि यह अंततः प्रदर्शित कहाँ होगा? कोड फ़ाइल और फ़ंक्शन नाम से? बल्कि अनाड़ी और मेरे साथ भंगुर लगता है।

सब सब में, मैं डुप्लिकेट की अनुमति देने की ओर झुक रहा हूं, लेकिन मैं एक सुसंगत नामकरण योजना खोजने के लिए संघर्ष कर रहा हूं जो इस का समर्थन करता है।

संपादित करें: इस प्रश्न के दो पहलू हैं: संसाधनों को कैसे व्यवस्थित करें (DRY बनाम डुप्लिकेट) और उन्हें कैसे नाम दें। अब तक, उत्तर पहले पहलू पर केंद्रित हैं। मैं नामकरण सम्मेलनों के बारे में कुछ प्रतिक्रिया की सराहना करता हूँ!


1
यदि आपके पास प्रत्येक सेट के साथ छोटे पैकेज हैं, तो यह सवाल उठता है कि क्या आप बहुत अधिक डुप्लिकेट देखेंगे। मैं डुप्लिकेट के साथ जाऊंगा और कोड में पहचानकर्ताओं के बारे में बहुत अधिक चिंता नहीं करूंगा।
मार्टिन बा ०

"यदि आप नहीं जानते कि स्ट्रिंग का एक विशिष्ट उपयोग कैसे किया जाता है, तो आपको यह नहीं पता होगा कि यह अंततः प्रदर्शित कहाँ होगा?" क्या यह डिजाइन के साथ दोष का संकेत नहीं होगा, जहां यह तर्क को मिलाता है (निर्णय लेना है कि इसे कहां दिखाना है) और प्रस्तुति (वास्तव में दिखाना)। आपके लिए क्षेत्रीय डेटा के साथ कुछ पाठ का निर्माण करना बहुत अजीब होगा, लेकिन इसे किसी भी अन्य आंतरिक डेटा ऑब्जेक्ट की तरह व्यवहार करना, जिसे आप चारों ओर ले जा सकते हैं।
अल्फा

जवाबों:


8

मैं दोहराव को स्वीकार करूंगा जब भी आप पूरी तरह से सुनिश्चित नहीं हो सकते हैं कि सभी मामलों में अर्थ बिल्कुल एक जैसा है।

यहां तक ​​कि अगर दो लेबल में हमेशा अंग्रेजी (या आपकी मूल जीभ) में एक ही स्ट्रिंग होती है, तो वे सभी भाषाओं में समान नहीं होंगे। दोहराव स्वीकार करने से आपको (या अनुवादकों को) ऐसी स्थितियों को संभालने के लिए आवश्यक लचीलापन मिल सकता है।

एक उदाहरण के रूप में: एक लेबल "स्थिति" पर विचार करें, जो - संदर्भ के आधार पर - जर्मन में "ज़स्टैंड" या "बेडिंगुंग" में अनुवादित हो सकता है (बहुत सारे अन्य संभावित अनुवादों में)।



2

कुछ डुप्लिकेट स्वीकार करें।

आप अतिरिक्त नियंत्रण बनाकर कुछ एकाधिक अनुवादों से बच सकते हैं। जैसे ए CancelButtonऔर OKButtonजो पहले से ही अपने पाठ को समाहित करते हैं, और अब रद्द करें / Abbrechen OK / OK को केवल एक बार अनुवादित करने की आवश्यकता है। लेकिन यह लगभग एक विशेष मामला है।


2

इस तरह से हम इसे अपनी कंपनी में संभाल रहे हैं:

नामकरण सम्मेलन: हम लेबल को उनके वर्ग / खंड / प्रपत्र / आदि के साथ जोड़कर नाम देते हैं। उदाहरण के लिए loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelएक लोड फ़ाइल संवाद से संबंधित सभी लेबल कर रहे हैं। हालांकि यह अंडरस्कोर नामकरण सम्मेलन सबसे आम नहीं है, हम इसे और अधिक मानक सम्मेलनों के पक्ष में करते हैं क्योंकि यह पठनीयता और "समूहता" में सुधार करता है: ध्यान दें कि यह देखना कितना आसान है कि लेबल किस तत्व से संबंधित है, और प्रत्येक लेबल लेबल की तुलना में क्या दर्शाता है। नाम दिया है loadFileLoadButton, loadFileNameLabelऔर loadFileCancel। आप सोच सकते हैं कि अंतर इतना बड़ा नहीं है, लेकिन जब आपके पास हजारों लेबल हैं, तो यौगिक प्रभाव इसके लायक है।

हेडर टिप्पणियां: लेबल नामों को प्रीफ़िक्स करने के लिए, हम स्पष्ट रूप से लेबल समूहों को परिभाषित करने के लिए संसाधन फ़ाइलों में "हेडर" टिप्पणियां भी जोड़ते हैं। इस प्रकार, कोई व्यक्ति किसी विशेष वर्ग / अनुभाग / प्रपत्र / आदि से संबंधित विशिष्ट लेबल को संशोधित या जोड़ना चाहता है, उस विशेष तत्व से संबंधित सभी लेबल केवल एक हेडर के नीचे, और आसानी से लेबल जोड़ने या संशोधित करने के लिए आगे बढ़ सकता है। यह जानते हुए कि वे किसी भी अन्य तत्वों (IMHO) के लिए अनुवाद नहीं तोड़ेंगे, यह भी एक बहुत मजबूत बिंदु है कि आपको दोहराव की अनुमति देने की आवश्यकता क्यों है)।

"न्यायोचित" डुप्लिकेट वांछनीय हैं: जैसा कि ऊपर उल्लेख किया गया है, ये प्रथाएं निश्चित रूप से डुप्लिकेट लेबल की ओर ले जाएंगी, लेकिन हम इसके साथ कोई समस्या नहीं देखते हैं (व्यापार के साधनों में इसे कैसे संभालना है)।

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

व्यापार के उपकरण: अपने अनुवाद करते समय जितना संभव हो उतना प्रभावी होने के लिए, आप अपने स्वयं के टूल का निर्माण कर सकते हैं जो समान लेबल की तलाश में हैं जो आपके बंडलों में मौजूद हैं, और उनके अनुवाद को नए लेबल के लिए डिफ़ॉल्ट मान के रूप में पेश करते हैं, या आप भी कर सकते हैं इस तरह की मौजूदा सेवाओं का उपयोग करें , जो कि मेरे द्वारा बताए गए जैसे उपकरण प्रदान करते हैं, जिससे नए लेबल का अनुवाद हवा हो जाता है (और भी बहुत बार अगर वे कई बार दोहराए जाते हैं, क्योंकि उपकरण आपको नए लेबल के लिए डिफ़ॉल्ट रूप से कई अनुवाद विकल्प प्रदान करेगा। )।

इसे सारांशित करना: औचित्यपूर्ण तरीके से दोहराए गए और लेबल वाले लेबल से वास्तव में अनुवादकों को अपना काम करने में मदद मिलती है। ज़्यादा समय। इसके बारे में जरा सोचें: उचित अनुवाद का चयन करने के लिए अनुवादक का सहायता करने के संदर्भ में एक लंबा रास्ता तय होता है। और "औचित्यपूर्ण" डुप्लिकेट को एक अनुवाद का चयन करने के संघर्ष को समाप्त करता है जो खराब रूप से कुछ संदर्भों को फिट करता है (लेकिन वैसे भी सबसे अच्छा समग्र फिट है)।

आशा है कि ये आपकी मदद करेगा!


1

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

हम एक ढांचे से बंधे थे, जहां संसाधन फ़ाइल में केवल अनुवाद के बाद अंग्रेजी वाक्यांशों की एक सूची शामिल थी (तेजी से देखने के लिए अंत में कुछ अनुक्रमण डेटा के साथ)।

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

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

उदाहरण के लिए, "ज़िप कोड दर्ज किया जाना चाहिए" दूसरे भाषा में "दर्ज ज़िप कोड होना चाहिए" के शाब्दिक अनुवाद करने की आवश्यकता हो सकती है। यदि आप एक वाक्य काटते हैं, तो आपको किसी अन्य भाषा में आवश्यक शब्दों के उलट नहीं मिलता है।

इसलिए अंग्रेजी में कुछ बुरी तरह से किए गए अनुवाद इतने हास्यास्पद लगते हैं, ऐसा करने वाले व्यक्ति ने केवल व्यक्तिगत शब्दों का अनुवाद किया, पूरे वाक्य का नहीं।

हमने हमेशा उन्हें तोड़कर बिना, वाक्यों को संपूर्ण रूप में अनुवादित करना सबसे अच्छा समझा। हमारे पास डेटा रखने के लिए स्थान धारक थे जिन्हें डालने की आवश्यकता थी (उदाहरण के लिए "भाग संख्या @ 1 निरर्थक है") और अनुवादक स्थान धारक को उस स्थिति में ले जा सकता है जो वे एक अच्छे अनुवाद के लिए चाहते थे।

हालाँकि हमने पाया कि उन स्थानों की अनुमति देना जो वास्तव में एक ही वाक्य का उपयोग करते हैं, या समान डेटा संकेत या समान बटन लेबल आदि, अनुवाद साझा करने के लिए ठीक थे। यह कभी भी एक मुद्दे के रूप में सामने नहीं आया और अनुवादक के लिए समय / लागत को बचाया।


बिल्कुल सही। हम भी ऐसा करते हैं। अनुवाद में कभी भी लेबल / वाक्यों को तोड़ने की कोशिश न करें।
मार्टिन बा

1
मुझे डर है कि वास्तव में मेरे सवाल का जवाब नहीं है। मैं बिल्कुल सहमत हूं कि वाक्यों को कभी भी तोड़ना नहीं चाहिए। हालाँकि, अधिकांश संसाधन वाक्य नहीं हैं, लेकिन सरल लेबल (बटन पाठ, तालिका शीर्षलेख, प्रपत्र लेबल आदि)।
डैनियल वुल्फ

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

मैंने स्पेनिश से और कई बड़े अनुप्रयोगों का अनुवाद करने का काम किया है, और मैं आपको बता सकता हूं कि यदि आपके पास सही अनुवाद उपकरण हैं, तो डुप्लिकेट एक मुद्दा नहीं है (वे भी वांछनीय हैं)। इसे प्रभावी ढंग से कैसे संभालना है, इसके लिए मेरा जवाब देखें।
carlossierra

0

नामकरण पर आपकी सोच अच्छी है।

उद्देश्य

  • स्थानीय पाठ के लिए एक सामान्य लेबल (अर्थात परिवर्तनशील नाम) को परिभाषित करें।
  • लेबल "माइंड साइज" होना चाहिए। यह है ... अस्वाभाविक होते हुए भी कम व्यावहारिक।
  • लेबल को एक सुसंगत प्रारूप का पालन करना चाहिए ताकि भविष्यवाणी और याददाश्त को अधिकतम किया जा सके।

कार्यान्वयन

  • अच्छी तरह से ज्ञात संक्षिप्तीकरण (यानी, संदेश = संदेश, lbl = लेबल, btn =% ...) के निरंतर उपयोग के साथ संज्ञानात्मक भार कम करें
  • उपकरण वर्णमाला सूचियों में चर / लेबल प्रस्तुत करते हैं, इसलिए संबंधित लेबल समूह एक साथ होने पर मानवीय खोज सर्वोत्तम होती है। नाम को सामान्य से सबसे विशिष्ट करने के लिए पदानुक्रमित बनाओ। (यानी msgFileMissing, msgFileSaved, msgFileDeleted)।
  • अंग्रेजी एक क्रिया-संज्ञा वाली भाषा है। कई (अधिकांश?) अन्य भाषाएं संज्ञा-क्रिया हैं। पदानुक्रमित समूहन के लिए संज्ञा-क्रिया सर्वोत्तम है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.