प्रलेखन और स्थानीयकरण के सिद्धांत, या न्यूनतम लागत पर अच्छा स्थानीयकरण कैसे प्राप्त करें

सभी को नमस्कार!

मेरा नाम डेनिसोव अलेक्जेंडर है। मैं Naumen के लिए काम करता हूं और Naumen Contact Center (NCC) सॉफ्टवेयर उत्पाद के दस्तावेजीकरण और स्थानीयकरण के लिए जिम्मेदार हूं।

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

परिचय

अक्सर एक कंपनी सॉफ्टवेयर स्थानीयकरण के बारे में सोचती है जब उत्पाद तैयार होता है और इसके लिए दस्तावेज लिखा जाता है। और कम समय में अच्छा स्थानीयकरण पाने के लिए और उस पर भारी मात्रा में संसाधनों को खर्च नहीं करने के लिए अक्सर कुछ करने में बहुत देर हो जाती है।

एक लेख में सभी समस्याओं और कठिनाइयों के बारे में विस्तार से लिखना असंभव है, इसलिए मैं दस्तावेज़ीकरण और स्थानीयकरण के मुख्य चरणों के बारे में थोड़ी बात करूंगा और मेरी राय में, सबसे महत्वपूर्ण मुद्दों पर कई को छू सकता हूं:

• सॉफ़्टवेयर विकास जीवन चक्र के कौन से चरण प्रलेखन और स्थानीयकरण की गुणवत्ता को प्रभावित करते हैं?
• प्रत्येक चरण में क्या और कब करना है?
• प्रत्येक चरण की समस्याओं और समस्याओं को हल करने के लिए उपकरणों की क्षमताओं का क्या दृष्टिकोण, उपयोग किया जा सकता है?
• एक org की तरह। क्या संरचना प्रलेखन और स्थानीयकरण को प्रभावित करती है?
• प्रलेखन के उपयोगकर्ताओं से प्रतिक्रिया प्राप्त करने का आयोजन कैसे करें?
• प्रत्येक चरण में समय और वित्तीय लागत कैसे बचाएं?

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

एनसीसी की विशेषताएं और विकास प्रक्रिया

Naumen कॉन्टैक्ट सेंटर बड़े कॉरपोरेट या आउटसोर्सिंग संपर्क केंद्रों के आयोजन के लिए एक परिष्कृत सॉफ्टवेयर है।

इस प्रणाली का दस्तावेजीकरण और स्थानीयकरण करने में क्या कठिनाई है:

1. सिस्टम बादल नहीं है।
2. जटिल सेटअप, विभिन्न प्रणालियों के साथ कई एकीकरण।
3. कई संस्करणों के लिए समर्थन।
4. पैराग्राफ 1-3 के परिणामस्वरूप, हमारे पास जटिल कार्यान्वयन और अपडेट हैं। प्रत्येक क्लाइंट का अपना संस्करण, अपना कॉन्फ़िगरेशन और विभिन्न प्रणालियों के साथ एकीकरण है।
5. प्रणाली बड़े पैमाने पर नहीं है, इसका उपयोग केवल बड़े व्यवसाय द्वारा किया जाता है। इसलिए, छोटे द्रव्यमान उत्पादों की तुलना में ग्राहकों की संख्या बहुत बड़ी नहीं है।
6. बड़ी संख्या में विशिष्ट शब्द।
7. मल्टी-रोल मॉडल। और इसका मतलब है कि प्रलेखन और इंटरफ़ेस प्रत्येक भूमिका की विशेषताओं (ज्ञान का स्तर और कार्यों की सुविधाओं) के अनुरूप होना चाहिए।
8. सिस्टम इंटरफेस में पाठ की लगभग 30,000 पंक्तियाँ होती हैं और लगभग 3000 पृष्ठों के जटिल तकनीकी दस्तावेज लिखे जाते हैं।
9. साल में 2-3 बार रिलीज़ होती है।
10. प्रत्येक रिलीज़ के बाद, लगभग 10% इंटरफ़ेस पाठ और प्रलेखन अद्यतन और पूरक होता है।
11. 3 भाषाएँ: रूसी (स्रोत), अंग्रेजी और जर्मन।

विकास जीवन चक्र

आइए सॉफ्टवेयर विकास के जीवन चक्र को देखें और केवल उन चरणों का चयन करें जो प्रलेखन और स्थानीयकरण से संबंधित हैं:

• सुविधा का विकास। इस चरण के हिस्से के रूप में, इंटरफ़ेस के लिए ग्रंथ विकसित किए गए हैं।
• दस्तावेजीकरण। इस चरण के हिस्से के रूप में, प्रलेखन विकसित किया गया है, जिसमें स्क्रीनशॉट और अन्य छवियों का निर्माण शामिल है।
• कई भाषाओं में इंटरफ़ेस का स्थानीयकरण।
• स्क्रीनशॉट और अन्य छवियों के स्थानीयकरण सहित अन्य भाषाओं में प्रलेखन का अनुवाद।

अब आइए कल्पना करें कि इंटरफ़ेस में एक छोटी सी गलती हुई थी। यह स्वचालित रूप से प्रत्येक चरण में, कई संस्करणों और भाषाओं पर लागू होता है।



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

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

इंटरफ़ेस में पाठ का संगठन

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



छवि एक साधारण बटन दिखाती है, यह मापदंडों के साथ कुछ रूप खोलता है, जहां इन मापदंडों को बदला जा सकता है। सिस्टम में ऐसे दर्जनों बटन हैं। रूसी में, इस तरह के बटन के लिए 3 विकल्प थे, अंग्रेजी में स्थानीयकरण पहले से ही 7 विकल्प थे।

इस स्थिति में, तुरंत इंटरफ़ेस की रेखाओं को साफ करने की बहुत इच्छा होती है। ऐसा करने के लिए, मैं निम्नलिखित नियम लागू करने का प्रस्ताव करता हूं:

• समूहों में सभी लाइनों का विभाजन।
  
  सभी लाइनों को इंटरफ़ेस तत्वों के प्रकार के अनुसार समूहों में विभाजित किया जाना चाहिए। भले ही लाइनों में एक ही पाठ हो, विभिन्न समूहों के लिए अलग-अलग अनुवाद नियम लागू हो सकते हैं। उदाहरण के लिए, अंग्रेजी में प्रत्येक शब्द के पहले अक्षर के लिए पूंजीकरण नियम। कुछ प्रकार के इंटरफ़ेस तत्वों के लिए, इसका उपयोग किया जाता है, दूसरों के लिए नहीं।
• डुप्लिकेट निकाल रहा है।
  
  प्रत्येक समूह में, यह सभी डुप्लिकेट लाइनों को हटाने के लिए समझ में आता है, अर्थात्, एक ही पाठ के साथ लाइनें। फिर रूसी और अन्य भाषाओं में एकमात्र विकल्प होगा। इससे अनुवाद लागत बचती है। मैं ध्यान देता हूं कि सबसे अधिक संभावना है कि दोहराई गई रेखाएं अभी भी बनी रहेंगी, क्योंकि कुछ मामलों में संदर्भ अलग हो सकता है। इसके अलावा, एक ही स्रोत पाठ के साथ ऐसी पंक्तियों का विभिन्न तरीकों से अनुवाद किया जा सकता है। उदाहरण के लिए, किसी व्यक्ति के नाम के संदर्भ में नाम, का अनुवाद पहले नाम के रूप में किया जा सकता है, और फ़ाइल नाम के संदर्भ में, बस नाम ।
• रेखा पहचानकर्ताओं के संदर्भ में जोड़ना।
  
  लाइन आइडेंटिफ़ायर में लाइन के आइडेंटिफ़ायर और उस समूह के समूह शामिल हो सकते हैं। यह आवश्यक है ताकि अनुवादक स्थानीयकरण नियम का चयन करने के लिए पहचानकर्ता का उपयोग कर सके। यदि हमारे पास ऐसे सही पहचानकर्ता हैं, तो समान पूंजीकरण त्रुटियों को जांचने और ठीक करने की प्रक्रिया को आसानी से स्वचालित किया जा सकता है।

दुर्भाग्य से, इन नियमों को एक बार में सभी मौजूदा 30,000 लाइनों पर लागू करने में बहुत समय लगता है। यहां हम प्रारंभिक चरण में हैं और धीरे-धीरे सबसे अधिक बार-बार दोहराई जाने वाली लाइनों को क्रम में रखते हैं और नई लाइनों के लिए नियम विकसित करते हैं। लेकिन आपको स्वीकार करना चाहिए, यह सुपर होगा यदि सभी नियमों को वर्तनी और तुरंत लागू किया गया था!

प्रलेखन और स्थानीयकरण प्रक्रिया

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

अनुवाद प्रलेखन के साथ एक ही बात।

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



यदि प्रक्रियाएँ समन्वित नहीं हैं, और हम समय पर सभी परिवर्तनों को ट्रैक नहीं करते हैं, तो "कुछ भी नहीं-कहीं भी" अनुरूप नहीं होगा।

दस्तावेज़ इंटरफ़ेस से मेल नहीं खाएगा। स्क्रीनशॉट इंटरफ़ेस और प्रलेखन के पाठ से मेल नहीं खाएगा।



स्थानीयकरण के साथ भी ऐसा ही है। स्रोत भाषा में इंटरफ़ेस और प्रलेखन का पाठ अन्य भाषाओं में इंटरफ़ेस और प्रलेखन के पाठ से मेल नहीं खाएगा।



हमने फैसला किया कि फिलहाल हम प्रत्येक नए चरण को शुरू करने का खर्च उठा सकते हैं।



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

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

शब्दावली मुद्दे

प्रलेखन और स्थानीयकरण के चरण में, हमें लगातार शब्दावली के साथ समस्याओं का सामना करना पड़ा:

• समान संस्थाओं को अलग-अलग कहा जाता था, और विभिन्न संस्थाओं को एक ही नाम दिया गया था।
• समान शब्दों का अनुवाद अलग-अलग तरीकों से किया गया था, और अलग-अलग शब्दों का एक ही तरीके से अनुवाद किया गया था।
• एक इकाई को उसकी बाल संस्थाओं के साथ समान किया जा सकता है, जिनमें यह शामिल है, या मूल संस्थाएं।
• किसी संस्था को निरूपित करने के लिए असफल या गलत शब्द चुने गए।

कुछ समय के लिए हमारे लिए विकास की प्रक्रिया इस तरह दिखी:

• विश्लेषक एक प्रोडक्शन लिख रहे हैं।
• परीक्षक उत्पादन का परीक्षण करते हैं।
• डेवलपर्स कोड।
• परीक्षार्थी परीक्षा का परिणाम देते हैं।

और जब इस प्रक्रिया को शब्दावली के साथ करने की कोशिश की गई, तो हमें ऐसे बहाने मिले:

• आप पूरी प्रक्रिया को धीमा कर देंगे।
• यह आमतौर पर इतना महत्वपूर्ण नहीं है।
• आपके पास उपकरण हैं, आप बाद में सब कुछ ठीक कर सकते हैं।

लेकिन "बाद में" यह पता चला कि हम सब कुछ ठीक नहीं कर सकते। उदाहरण के लिए, ऐसी परिस्थितियाँ थीं, जब गलत तरीके से समझी गई शब्दावली के कारण, सिस्टम ऑब्जेक्ट्स को गलत पदानुक्रम स्तरों पर रखा गया था या उन्हें गलत समूहों में जोड़ा गया था।

अब हम परीक्षण सेट करने के साथ समानांतर में इंटरफ़ेस के नियम और पाठ की जांच कर रहे हैं। यही है, जबकि परीक्षक अपनी टिप्पणी लिखते हैं, हम अपना खुद का लिखते हैं।



उत्पादन परीक्षण के दौरान हम क्या करते हैं:

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

नए शब्दों का खुलासा करते समय, हम उन्हें शब्दकोष में जोड़ते हैं, जबकि:

• एक परिभाषा या संदर्भ जोड़ें।
• हम अन्य शर्तों के साथ संबंध दर्शाते हैं (माता-पिता और बच्चे की शर्तों को इंगित करें)।
• हम तुरंत अंग्रेजी अर्थ को इंगित करने की कोशिश कर रहे हैं, क्योंकि अंग्रेजी नाम चुनने के बाद यह कभी-कभी स्पष्ट हो जाता है कि रूसी को बहुत सही तरीके से नहीं चुना गया है।

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

कुछ दस्तावेज़ीकृत

दस्तावेज करते समय हम जिन सिद्धांतों का पालन करते हैं:

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

अब मैं प्रलेखन प्रक्रिया के कुछ सबसे महत्वपूर्ण पहलुओं के बारे में बात करूँगा।

पाठ का पुन: उपयोग करें

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



क्या लाभ हैं:

• इंटरफ़ेस तत्वों के पाठ में त्रुटियों को बाहर रखा गया है यदि वे प्रलेखन में उल्लिखित हैं। दस्तावेज़ में इंटरफ़ेस तत्वों के पाठ हमेशा इंटरफ़ेस के ग्रंथों के समान होते हैं।
• यदि इंटरफ़ेस में टेक्स्ट की लाइनें बदल गई हैं, तो वे स्वचालित रूप से प्रलेखन में बदल जाते हैं।
• प्रलेखन में इंटरफ़ेस तत्वों के ग्रंथों का अनुवाद करते समय त्रुटियों को बाहर रखा गया है।
• एक अनुवादक काम करने में कम समय व्यतीत करता है।

प्रलेखन में कई डुप्लिकेट वाक्य हैं। उदाहरण के लिए, एक वाक्य जैसे - " सेव बटन पर क्लिक करें।" एकल स्रोत प्रणालियों में, इस तरह के प्रस्ताव को एक स्निपेट में रखा जा सकता है। एक स्निपेट एक ऐसी छोटी फ़ाइल होती है जिसे प्रलेखन के अन्य पृष्ठों में डाला जा सकता है।



जैसा कि आप देख सकते हैं, स्निपेट में सेव बटन का पाठ भी चर से प्रतिस्थापित किया गया है।

यह निम्नलिखित लाभ प्रदान करता है:

• अर्थ में समान वाक्य हर जगह समान हैं, जिसका अर्थ है कि पाठ की एकरूपता बढ़ जाती है।
• पुन: उपयोग के माध्यम से प्रलेखन विकसित करने की लागत कम हो जाती है।
• ऐसे वाक्यों का अनुवाद केवल 1 बार किया जाता है। यह अनुवादक की लागत को कम करता है।

स्क्रीनशॉट और अन्य चित्र

हमारे प्रलेखन में, हम अक्सर स्क्रीनशॉट और अन्य छवियों का उपयोग करते हैं जिनमें पाठ हो सकता है।

अपने दम पर विभिन्न भाषाओं में स्क्रीनशॉट लेने के लिए, प्रत्येक स्क्रीनशॉट के तहत हम उस पर लिखे गए पाठ को लिखते हैं। यह पाठ टैग किया गया है और समाप्त प्रलेखन में प्रकट नहीं होता है। इससे पहले कि हम प्रलेखन का अनुवाद करें, हम स्क्रीनशॉट के लिए ग्रंथों का अनुवाद करते हैं। और प्रलेखन के अनुवाद के दौरान हम तकनीकी लेखकों द्वारा भाषा के ज्ञान के बिना स्क्रीनशॉट लेते हैं।

स्क्रीनशॉट का उपयोग करना, अन्य कठिनाइयां हैं। उदाहरण के लिए, यदि सभी इंटरफ़ेस पाठ की एक पंक्ति को बदलते हैं, तो सभी परिवर्तनों को कैसे ट्रैक किया जाए, जिसका उपयोग 50 स्थानों पर किया जाता है?

फिर प्रलेखन में उन्हें बदलने के लिए इन 50 स्थानों के सभी स्क्रीनशॉट कैसे ढूंढें?

इस समस्या को हल करने के लिए, हम QVisual टूल का उपयोग करते हैं जिसे हमने टिंकऑफ में विकसित किया था। इसके साथ काम करने की प्रक्रिया इस प्रकार है:

1. दस्तावेज़ीकरण के विकास के दौरान, प्रत्येक स्क्रीनशॉट के तहत हम स्टैंड के लिए एक लिंक बनाते हैं जहां यह स्क्रीनशॉट लिया जाता है।
2. एक निश्चित बिंदु पर, हम सभी लिंक की एक सूची तैयार करते हैं।
3. हम प्राप्त सूची को QVisual में लोड करते हैं।
4. QVisual उत्पाद के एक संस्करण के माध्यम से चलता है और स्क्रीनशॉट का एक सेट लेता है।
5. अगला, हम उसी लिंक का उपयोग करके उत्पाद के नए संस्करण और QVisual को इसके माध्यम से चलाते हैं।
6. फिर QVisual ने स्क्रीनशॉट के 2 सेट की तुलना की और एक रिपोर्ट तैयार की। रिपोर्ट में, आलेखीय रूप से, आप दो संस्करणों के बीच अंतर देख सकते हैं। एक उदाहरण नीचे है। आप तुरंत देख सकते हैं कि स्क्रीनशॉट के नए संस्करण में एक अतिरिक्त फ़ील्ड उपयोगकर्ता इंटरफ़ेस भाषा दिखाई दी है।
7. अगला, हम प्रत्येक भाषा के लिए तुलना प्रक्रिया (पृष्ठ 1-6) दोहराते हैं।
8. हम रिपोर्ट लेते हैं और प्रलेखन में स्क्रीनशॉट के माध्यम से जाते हैं।

इस प्रकार, हम कई मैनुअल स्क्रीनशॉट चेक की लागत को कम करते हैं। इसके अलावा, मैन्युअल रूप से सभी त्रुटियों की पहचान करना हमेशा संभव नहीं होता है, आप बस कुछ अनदेखी कर सकते हैं।

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

इंटरफ़ेस स्थानीयकरण

इंटरफ़ेस को स्थानीय बनाने से पहले, यदि यह पहले से नहीं किया गया है, तो आपको सभी शब्दावली शब्दों का अनुवाद करने की आवश्यकता है।

जब शब्दकोष का अनुवाद किया जाता है, तो स्थानीयकरण शुरू हो सकता है। इस प्रक्रिया में, हम निम्नलिखित सिद्धांतों का पालन करते हैं:

• शब्दावली का उपयोग करें।
• हम अनुवाद स्मृति का उपयोग करते हैं।
• हम शैली गाइड का उपयोग करते हैं।
• हम एक संदर्भ का उपयोग करते हैं।
• हम स्वचालित गुणवत्ता आश्वासन (QA) का उपयोग करते हैं।

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

संदर्भ प्रदान करने के कई तरीके हो सकते हैं:

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

प्रलेखन का अनुवाद

प्रलेखन का अनुवाद करते समय हम जिन सिद्धांतों का पालन करने की कोशिश करते हैं:

• सबसे पहले, हम स्क्रीनशॉट और अन्य छवियों के लिए ग्रंथों का अनुवाद करते हैं। जैसा कि मैंने ऊपर लिखा था, स्क्रीनशॉट को प्रलेखन के अनुवाद के साथ समानांतर में लिया गया है। यह स्क्रीनशॉट के लिए अनुवादित ग्रंथों का उपयोग करते हुए स्टैंड पर किया जाता है।
• हम केवल परिवर्तित और नई लाइनों का अनुवाद करते हैं। पहले 100% मैच के साथ अनुवादित लाइनें बस नहीं दिखती हैं। हां, आप प्रत्येक रिलीज़ पर सभी दस्तावेज़ों को फिर से पढ़ सकते हैं, लेकिन इस तथ्य को ध्यान में रखते हुए कि प्रत्येक रिलीज़ को 10% पाठ के बारे में अपडेट किया जाता है, शेष 90% पाठ को घटाना एक अनुचित लागत है।
• शब्दावली का उपयोग करें। इंटरफ़ेस के स्थानीयकरण के चरण में शब्दावली का अनुवाद पहले किया जाना चाहिए।
• हम मेमोरी ट्रांसलेशन डॉक्यूमेंट का उपयोग करते हैं।
• हम मेमोरी ट्रांसलेशन इंटरफ़ेस का उपयोग करते हैं।
• हम शैली गाइड का उपयोग करते हैं।
• हम स्वचालित गुणवत्ता नियंत्रण (क्यूए) का उपयोग करते हैं।

संगठनात्मक संरचना और प्रतिक्रिया

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



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

मेरी राय में, सभी भाषाओं में सभी ग्रंथों के लिए एक विभाग जिम्मेदार होना चाहिए।

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

मैं एक उदाहरण दूंगा।

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

यह पता चला कि अनुवादक उन वाक्यों को देखता है जो अर्थ में समान हैं, लेकिन विभिन्न तरीकों से, और उनके लिए एक ही अनुवाद बनाते हैं। हमने कार्य शुरू किया और तकनीकी लेखक ने एक स्निपेट के अर्थ के भीतर एक ही पाठ के सभी विभिन्न संस्करणों को बदल दिया। अब ऐसी बार-बार होने वाली त्रुटियां नहीं होंगी। पेशेवरों को उनका विश्लेषण करने के लिए समय नहीं देना होगा, और भविष्य में नई भाषाओं में अनुवाद करना आसान होगा।



सामान्य स्थिति में, यदि अनुवादक के अनुवाद के दौरान प्रश्न हैं, तो हमारे लिए यह पहले से ही एक "घंटी" है कि शुरुआती चरणों में कुछ गलत है और हमें सुधार कार्य करने की आवश्यकता है।

क्या गुणवत्ता प्रलेखन की जरूरत है

इससे पहले कि आप सभी भाषाओं में सही दस्तावेज बनाने की कोशिश करें, यह विचार करने योग्य है कि गुणवत्ता की क्या आवश्यकता है? अतिरिक्त प्रश्न इस प्रश्न का उत्तर देने में मदद करेंगे:

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

दस्तावेज़ीकरण प्रूफरीडिंग और उपयोगकर्ता प्रतिक्रिया

यदि आप दस्तावेज़ पढ़ने का निर्णय लेते हैं:

• सभी को घटाया नहीं जा सकता।
  
  प्रलेखन के उपयोग पर आंकड़े बनाएं और प्रूफरीडिंग के लिए प्रस्तुत करें, उदाहरण के लिए, शीर्ष 50 पृष्ठ जो सैकड़ों और हजारों उपयोगकर्ताओं द्वारा पढ़े जाते हैं। यदि कुछ पृष्ठों को वर्ष में 1-2 बार पढ़ा जाता है, तो उन्हें उपेक्षित किया जा सकता है।
• .
  
  CAT-. , (, ), .
• , , , .
• , .

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

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

अनुवादित प्रलेखन को भागीदारों द्वारा भी पढ़ा जा सकता है। आप उनके साथ ऐसे समझौतों का निष्कर्ष निकाल सकते हैं। साथी आपको सभी टिप्पणियां भेजता है, लेकिन साथ ही वह सिस्टम को समझता है।

उपयोगकर्ता क्या प्रतिक्रिया भेजता है:

• .
  
  - , . . , Ctrl+Enter . . .
• .
  
  , . , , .
• यूजर्स अपने लिए ऐसा करते हैं।
  
  यही है, वे अपने लिए और अन्य उपयोगकर्ताओं के लिए दस्तावेज़ को बेहतर बनाने में मदद करते हैं, इससे संतुष्टि प्राप्त करते हैं। अगली बार उन्हें फिर से जानकारी की आवश्यकता होती है (जिसमें कोई त्रुटि थी या जो गायब थी), वे इसे प्रलेखन में पाएंगे और उन्हें स्वयं ग्राहक को जवाब नहीं लिखना होगा। वे बस उस ग्राहक को लिंक भेजते हैं जिसने तकनीकी सहायता से संपर्क किया था। इस तरह वे अपने और अपने सहयोगियों के लिए लागत कम कर देते हैं।

मैं ध्यान देता हूं कि हम केवल दस्तावेज़ के वर्तमान संस्करण में टिप्पणियों को ठीक करते हैं, अर्थात्, जो अभी भी विकास के अधीन है। हम मानते हैं कि नए संस्करणों पर जितना संभव हो उतना ध्यान देना बेहतर है और पुराने संस्करणों का समर्थन करने में बहुत समय बिताने की तुलना में कुछ गलतियां करना संभव है।

निष्कर्ष

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

सबसे पहले, यह पता करें कि इस समय वास्तव में क्या आवश्यक है और बस इतना ही करें, और जैसे-जैसे आपकी आवश्यकताएं बढ़ती हैं, लागत में वृद्धि करें।

यह सामान्य रूप से प्रलेखन और स्थानीयकरण की प्रक्रियाओं के बारे में एक काफी सामान्य लेख था। भविष्य में मैं संकीर्ण विषयों के बारे में लिखने की कोशिश करूंगा।

अंत तक पढ़े तो धन्यवाद! मैं काम करने और अपने प्रलेखन और स्थानीयकरण प्रक्रियाओं को डीबग करने में सफलता की कामना करता हूं!

मुझे सवालों के जवाब देने, आपके विचारों और विचारों पर चर्चा करने में खुशी होगी!