तकनीकी शब्दावली, कैपिटलाइज़ेशन और अनूदित लेबलों की प्रूफरीडिंग कैसे करें
तकनीकी दस्तावेज़ों की समीक्षा करते समय, याददाश्त या किसी एक कैपिटलाइज़ेशन नियम पर निर्भर रहने के बजाय प्रत्येक पद (term) की जाँच एक स्पष्ट शब्दावली तालिका से करें। स्वीकृत रूप, वह वर्तनी और केस जो पाठकों को दिखना चाहिए, स्वीकार्य रूप, शाब्दिक कोड या API पहचानकर्ता, और ऐसे किसी भी अनुवाद को दर्ज करें जिस पर निर्णय होना अभी बाकी है। इसके बाद गद्य (prose), इंटरफ़ेस लेबल और पहचानकर्ताओं को अलग-अलग मदों के रूप में प्रूफरीड करें। यह विधि असंगत शब्दावली को पकड़ती है और साथ ही उन नामों और कोड को सुरक्षित रखती है जिनका सटीक बने रहना आवश्यक है।
कैपिटलाइज़ेशन का केवल एक नियम हर पद का समाधान क्यों नहीं कर सकता?
स्टाइल गाइड उपयोगी डिफ़ॉल्ट प्रदान करती हैं, लेकिन किसी उत्पाद या क्षेत्र (domain) में ऐसे स्थापित नाम हो सकते हैं जिनके लिए अलग व्यवहार की आवश्यकता होती है। Google की डेवलपर गाइड आधिकारिक उत्पाद नामों और कोड रूपों को सुरक्षित रखते हुए, शीर्षकों, सूचियों और तालिकाओं के लिए मानक अमेरिकी अंग्रेज़ी कैपिटलाइज़ेशन और सेंटेंस केस की सिफ़ारिश करती है। Microsoft की गाइड भी सेंटेंस-स्टाइल कैपिटलाइज़ेशन का समर्थन करती है, लेकिन स्पष्ट रूप से अपने ब्रांड, उत्पादों और सेवाओं जैसे व्यक्तिवाचक संज्ञाओं (proper nouns) के लिए कैपिटलाइज़ेशन को सुरक्षित रखती है। उनका साझा डिफ़ॉल्ट केवल एक शुरुआती बिंदु है, न कि इस बात का प्रमाण कि कोई दिया गया तकनीकी पद सामान्य (generic) है। [Google का कैपिटलाइज़ेशन मार्गदर्शन](https://developers.google.com/style/capitalization) [Microsoft का कैपिटलाइज़ेशन मार्गदर्शन](https://learn.microsoft.com/en-us/style-guide/capitalization)
एक शब्द सूची (word list) सामान्य कैपिटलाइज़ेशन पृष्ठ की तुलना में एक अलग प्रश्न का उत्तर दे सकती है: किसी विशिष्ट संपादकीय गाइड में विशेष पदों के लिए कौन सी वर्तनी या उपयोग को प्राथमिकता दी जाती है। उदाहरण के लिए, Google की शब्द सूची उन प्रविष्टियों के लिए पाठकों को अपने पसंदीदा शब्दकोश की ओर निर्देशित करती है जिन्हें यह कवर नहीं करती है, और शैली मार्गदर्शन को आधिकारिक दस्तावेज़ीकरण में तकनीकी परिभाषा की जाँच से अलग करती है। यह अलगाव उपयोगी है: संपादकीय निरंतरता और तकनीकी शुद्धता को प्रत्येक प्रश्न के लिए उपयुक्त स्रोतों से साक्ष्य की आवश्यकता होती है। [Google की शब्द सूची](https://developers.google.com/style/word-list)
प्रूफरीडिंग शब्दावली तालिका में क्या होना चाहिए?
ऐसे प्रत्येक पद के लिए एक पंक्ति बनाएं जिसे असंगत रूप से बदला जा सकता है या जिसका गलत अनुवाद हो सकता है। यह काल्पनिक उदाहरण फ़ील्ड और निर्णय के तर्क को दर्शाता है; "Sync token" और इसका अनुवाद केवल उदाहरण के लिए हैं, किसी वास्तविक उत्पाद या स्वीकृत शब्दावली के दावे नहीं हैं।
तालिका का कार्य निर्णयों और उनकी सीमाओं को सुरक्षित रखना है। किसी अनुमत लोअरकेस रूप को अनजाने में दूसरा उत्पाद नाम नहीं बनना चाहिए; किसी पहचानकर्ता को गद्य से मिलाने के लिए "सुधारा" नहीं जाना चाहिए; और किसी अनिर्णीत अनुवाद को स्पष्ट रूप से अनिर्णीत ही दिखना चाहिए। जब कोई आधिकारिक स्रोत स्थानीय शब्दावली संग्रह (glossary) के साथ मेल न खाए, तो रूपों को एक अस्पष्ट सूची में मिलाने के बजाय विरोध और अंतिम निर्णय के स्रोत को दर्ज करें।
प्रदर्शित की जाने वाली वर्तनी और केस का निर्णय आप कैसे करते हैं?
सबसे पहले यह पहचानें कि पद किसका संदर्भ देता है: एक सामान्य अवधारणा, एक ब्रांड या उत्पाद का नाम, एक UI लेबल, या एक शाब्दिक पहचानकर्ता। आधिकारिक रूप के लिए प्रासंगिक उत्पाद दस्तावेज़ या शब्दावली संग्रह की जाँच करें। फिर सामान्य गद्य, शीर्षकों और लेबलों पर लक्षित प्रकाशन के शैली नियमों को लागू करें, नामों और पहचानकर्ताओं के प्रलेखित अपवादों को बनाए रखें। Google अनावश्यक कैपिटलाइज़ेशन के ख़िलाफ़ सलाह देता है और केवल केस के आधार पर अर्थों में अंतर करने के प्रति चेतावनी देता है; Microsoft भी अपने सेंटेंस-स्टाइल दृष्टिकोण में वाक्य की शुरुआत और व्यक्तिवाचक संज्ञाओं को छोड़कर लोअरकेस का उपयोग करने के लिए कहता है। [Google कैपिटलाइज़ेशन मार्गदर्शन](https://developers.google.com/style/capitalization) [Microsoft कैपिटलाइज़ेशन मार्गदर्शन](https://learn.microsoft.com/en-us/style-guide/capitalization)
इसके बाद, जहाँ उपयुक्त हो, लक्षित संगठन की शब्द सूची और शब्दकोश के साथ रूप की तुलना करें। स्रोत और उसके संस्करण या जाँच की तिथि को दर्ज करें ताकि कोई अन्य संपादक इस निर्णय की पुनरावृत्ति कर सके। किसी आकर्षक दिखने वाली कैपिटलाइज़्ड वर्तनी, खोज परिणाम, या अंग्रेज़ी पद से मिलते-जुलते अनुवाद से आधिकारिक स्थिति का अनुमान न लगाएं। यदि स्रोतों में असहमति है या वे रूप को निर्दिष्ट करने में विफल रहते हैं, तो अनुमान को स्थापित शब्दावली के रूप में प्रस्तुत करने के बजाय निर्णय के लिए उस पंक्ति को फ़्लैग करें।
अनुवादों और इंटरफ़ेस लेबलों की जाँच कैसे की जानी चाहिए?
अनुवाद को अर्थ और संदर्भ के निर्णय के रूप में मानें, न कि एक यांत्रिक कैपिटलाइज़ेशन रूपांतरण के रूप में। एक लेबल इंटरफ़ेस, स्थापित स्थानीयकृत उत्पाद शब्दावली, या लक्षित भाषा में एक अलग व्याकरणिक रूप से सीमित हो सकता है। उम्मीदवार की तुलना स्वीकृत स्थानीयकृत सामग्रियों और उस संदर्भ से करें जिसमें पाठक इसे देखेंगे। यदि कोई आधिकारिक स्थानीयकृत रूप उपलब्ध नहीं है, तो अनुवाद को अनिर्णीत चिह्नित करें और उचित शब्दावली निर्णय का अनुरोध करें; कोई तथाकथित आधिकारिक समकक्ष स्वयं न गढ़ें।
पद के निर्णय के बाद, वास्तविक लेबल को उसके स्थान पर ही प्रूफरीड करें। जांचें कि क्या कैपिटलाइज़ेशन चुनी गई भाषा के नियमों और लागू उत्पाद या हाउस स्टाइल का पालन करता है। मूल लेबल को उसके स्रोत और स्थिति के साथ शब्दावली रिकॉर्ड में दृश्यमान रखें, ताकि भविष्य में कोई संपादन किसी अस्थायी अनुवाद को स्वीकृत न समझ बैठे। यदि निर्देशों में भी लेबल का संदर्भ दिया गया है, तो सत्यापित करें कि गद्य में स्क्रीन पर दिखने वाले समान शब्दों का ही उल्लेख किया गया है।
आप कोड और API पहचानकर्ताओं की सुरक्षा कैसे करते हैं?
केस बदलने से पहले शाब्दिक स्ट्रिंग्स को संपादकीय पाठ से अलग करें। प्रासंगिक API संदर्भ, स्कीमा, कोड, या इंटरफ़ेस के साथ वर्ण-दर-वर्ण (character for character) पहचानकर्ताओं की तुलना करें। जहाँ स्रोत उन्हें परिभाषित करता है, वहाँ अंडरस्कोर, कैपिटलाइज़ेशन, स्पेसिंग और विराम चिह्नों को सुरक्षित रखें; शैली का मानकीकरण आसपास की व्याख्या में होता है, शाब्दिक मान में नहीं। Google की गाइड आधिकारिक नामों में या उनका उपयोग करने वाले कोड का संदर्भ देते समय विशेष रूप से ऑल-कैप्स या कैमल-केस (camel-case) रूपों की अनुमति देती है। [Google कैपिटलाइज़ेशन मार्गदर्शन](https://developers.google.com/style/capitalization)
एक व्यावहारिक समीक्षा शब्दावली तालिका में सुरक्षित पहचानकर्ताओं को चिह्नित करती है और फिर उस संदर्भ के विरुद्ध प्रत्येक उपयोग की जाँच करती है। यदि कोई गद्य वाक्य कोड-रूप वाले पद का उपयोग एक सामान्य संज्ञा के रूप में करता है, तो तय करें कि शाब्दिक पहचानकर्ता को कोड फ़ॉर्मेटिंग में बरकरार रखते हुए इसे पाठक-अनुकूल शब्दों में समझाया जाए या नहीं। जब आधिकारिक परिभाषा स्वयं अस्पष्ट हो, तो अनिश्चितता को दर्ज करें; एक स्टाइल गाइड किसी API के व्यवहार या कैनोनिकल फ़ील्ड नाम को स्थापित नहीं कर सकती है।
एक विश्वसनीय प्रूफरीडिंग क्रम क्या है?
यह क्रम एक प्रूफरीडिंग सहायता है, न कि कोई स्वचालित अनुवाद या सार्वभौमिक केसिंग नियम। इसका मूल्य यह है कि यह प्रत्येक संपादकीय निर्णय को निरीक्षण योग्य बनाता है: कौन सा रूप चुना गया था, यह कहाँ से आया, यह कहाँ लागू होता है, और किस पर अभी भी निर्णय की आवश्यकता है। एक छोटे दस्तावेज़ के लिए, एक संक्षिप्त तालिका पर्याप्त हो सकती है; एक बड़े शब्दावली सेट के लिए, टीम के स्थापित शब्दावली वर्कफ़्लो में समान फ़ील्ड बनाए रखें।