संपादन करते समय मैं किन बातों के बारे में सोचता हूँ (2019)

• संपादन केवल वाक्यों को संवारने से पहले यह तय करने की प्रक्रिया है कि लेख वास्तव में क्या कहना चाहता है और उसका पाठक कौन है; और यही मूल सिद्धांत ईमेल, दस्तावेज़, ब्लॉग और उपन्यास पर भी लागू किए जा सकते हैं
• लेख की शुरुआत और अंत में मुख्य बात को फिर से रेखांकित करना, और “this/that” जैसे संकेतवाचक शब्दों के साथ संज्ञा जोड़ना, पाठक को संदर्भ से भटकने नहीं देता और स्पष्टता बढ़ाता है
• अनावश्यक शब्द हटाने, निर्देशों को आज्ञार्थक रूप में बदलने, और लंबे वाक्यों व “of/for” संरचनाओं को तोड़ने से अर्थ अधिक जल्दी पहुँचता है
• passive voice, adverb, jargon और cliché कर्ता, सटीक अर्थ और पाठक-सीमा को धुंधला कर सकते हैं, इसलिए उन्हें अधिक ठोस verbs और व्याख्या से बदलना बेहतर है
• अच्छा संपादन नियमों का अंधानुकरण नहीं है, बल्कि यह है कि आप अपने संदेश के अनुरूप भाषा-चयन को सचेत रूप से करें और अनावश्यक अभिव्यक्तियाँ हटा दें

---

पहले यह तय करें कि लेख वास्तव में क्या कह रहा है

• वाक्य-स्तर के संपादन में जाने से पहले यह जाँचना चाहिए कि लेख अपनी मंशा को वास्तव में व्यक्त कर रहा है या नहीं
• हर लेख के लिए एक व्यक्तिगत preamble लिख लेने से संपादन का मानदंड बन जाता है
  • मुख्य प्रश्न हैं: “मुख्य बिंदु क्या है” और “यह किसके लिए लिखा जा रहा है”
  • इस जानकारी को दस्तावेज़ के सबसे ऊपर लिखकर, लेखन और संपादन के दौरान वास्तविक सामग्री से तुलना की जाती है
• यदि किसी ब्लॉग पोस्ट का सार एक-दो वाक्यों में नहीं बताया जा सकता, तो एक सुसंगत लेख लिखना कठिन होता है
• Writers Studio की रचनात्मक लेखन कक्षाओं में हर असाइनमेंट के लिए इच्छित narrator, tone और mood सहित preamble लिखा जाता है, और मूल्यांकन पसंद के बजाय तकनीक और इरादे की सफलता पर केंद्रित होता है

दोहराव पाठक को साथ बनाए रखने का साधन है

• भले ही मुख्य बात पर्याप्त स्पष्ट लगे, लेख की शुरुआत और अंत में उसे फिर से कहना पाठक को बात बेहतर ढंग से पकड़ने में मदद करता है
• documentation tutorials में आम तौर पर यह संरचना अच्छी होती है: क्या किया जाएगा उसका परिचय, फिर प्रक्रिया, फिर यह सत्यापित करना कि काम सही हुआ या नहीं
• ब्लॉग पोस्ट के लिए भी पहले विषय का परिचय, फिर मुख्य भाग में उसका विस्तार, और अंत में छोटा सार उपयुक्त होता है
• भाषा-स्तर पर भी दोहराव ज़रूरी है
  • demonstrative pronouns “this”, “that” का अकेले उपयोग करने के बजाय, वे किस ओर संकेत कर रहे हैं यह बताने के लिए संज्ञा जोड़ें
  • “To solve this” की तुलना में “To solve this shortage” अधिक स्पष्ट है
  • “That will take you to the home screen” की तुलना में “Successfully authenticating will take you to the home screen” अधिक साफ़ है
• जो बात लेखक को दोहराव लगे, वही पाठक के लिए लेख का पीछा करना आसान बनाने वाली स्पष्टता हो सकती है

सरलीकरण: अर्थहीन शब्दों को हटाना

• संपादन का सबसे महत्वपूर्ण काम उन शब्दों को हटाना है जो अर्थ में योगदान नहीं करते
  • “You will need to run this script” को “Run this script” तक घटाया जा सकता है
  • “You can aid in readability by making sure…” को “Make sure…” किया जा सकता है
• किसी खास कारण के बिना, जितनी जल्दी हो सके मुख्य बिंदु पर पहुँचना चाहिए; अतिरिक्त शब्दों और सजावटी वाक्य-रचना में अर्थ को दबाना नहीं चाहिए

• निर्देशों को आज्ञार्थक रूप में बदलें

  • निर्देशों में “You should X”, “You can X” को क्रिया के imperative mood में बदलना अधिक संक्षिप्त होता है
  • “You should save the file to your home directory” बन जाता है “Save the file to your home directory”
  • यह बदलाव शब्द कम करता है और पाठक को सीधे कार्रवाई की ओर ले जाता है

• “of” और “for” संरचनाएँ कम करें

  • “of” या “for” से जुड़ी संरचनाओं को इस तरह फिर से लिखा जा सकता है कि जानकारी संज्ञा से पहले आ जाए, जिससे वाक्य अधिक कुशल हो जाता है
  • “The manager of the team responsible for marketing” बन जाता है “The marketing team’s manager”
  • इस तरह बदला गया वाक्य पाठक को हर खंड पर समझ फिर से समायोजित किए बिना अर्थ जल्दी पकड़ने देता है

• लंबे वाक्य तोड़ना और comma का उपयोग

  • लंबे वाक्यों को कई छोटे वाक्यों में बाँटना बेहतर होता है
  • Acme project के उदाहरण में एक ही वाक्य में milestone, server environment, build time improvement और XYZ plan की तुलना सब कुछ था; संशोधित रूप में इसे तीन वाक्यों में बाँटा गया
  • संशोधित रूप अलग-अलग बताता है कि non-staging server, Foobaz environment में चलता है, build समय 10 मिनट से कम हो गया, और XYZ plan में पहले यह 1 घंटे से अधिक लेता था
  • सही जगह comma जोड़ने से पाठक पहले हिस्से को समझकर फिर बाकी पढ़ सकता है
  • “If you’re looking for me, I’ll be in my office”
  • “Due to the fog, our flight was delayed”
  • जब वाक्य की शुरुआत में subordinate clause आती है, तो comma ज़रूरी होता है, और यह comma पढ़ने में मदद देने वाला processing point बनता है

ऐसे प्रयोग कम करें जो कर्ता और अर्थ को धुंधला करते हैं

• passive voice हटाना

  • passive voice यह छिपा देता है कि कार्रवाई किसने या किस चीज़ ने की
  • passive संरचना को active voice में बदलने से पाठक कार्रवाई को सही व्यक्ति या वस्तु से जोड़ पाता है, जिससे वाक्य अधिक स्पष्ट हो जाता है
  • “The fire alarm was pulled and the building was evacuated” की जगह “The fire marshal pulled the alarm and the employees evacuated the building” कर्ता को सामने लाता है
  • “Millions of dollars were embezzled from the company” की जगह “Two executives embezzled millions of dollars from the company” यह बताता है कि काम किसने किया
  • सिस्टम-विवरण में यदि लिखा जाए “An alert is triggered and the job is started”, तो यह स्पष्ट नहीं होता कि कौन-सी service alert trigger करती है और कौन-सा component job शुरू करता है
  • तकनीकी दस्तावेज़ में अगर कार्रवाई का कर्ता न बताया जाए, तो precision घटती है

• adverb की जगह ठोस verbs और विवरण लिखें

  • adverb को लगभग हमेशा अधिक ठोस verb या विवरण से बदला जा सकता है
  • “He laughed loudly” में “loudly” पाठक को हँसी की तीव्रता या भाव का अंदाज़ा लगाने पर छोड़ देता है
  • यदि वास्तविक आशय यह है कि “वह इतनी ज़ोर से हँसा कि पूरे रेस्तराँ ने मुड़कर देखा”, तो उस स्थिति को सीधे वर्णित करना अधिक ठोस है
  • “Basically”, “Essentially” जैसे adverb अक्सर hedge की तरह इस्तेमाल होते हैं, इसलिए उन्हें हटाकर बात सीधे कहना बेहतर है

पाठक के ज्ञान और tone को मानकर न चलें

• संक्षेप और अवधारणाओं की व्याख्या

  • जिस विषय को आप अच्छी तरह जानते हैं, उसके बारे में लिखते समय पाठक की अनजान पृष्ठभूमि भूल जाना आसान है
  • abbreviations और initialisms को पहली बार आने पर पूरा लिखें, फिर कोष्ठक में उसका संक्षेप दें, और उसके बाद केवल संक्षेप का उपयोग करें
  • “TTFB” को पहली बार “time to first byte (TTFB)” के रूप में लिखें
  • जब कोई अवधारणा पहली बार आए, तो उसके साथ छोटा-सा विवरण जोड़ने से पाठक को साथ बने रहना आसान होता है
  • TTFB यह मापता है कि उपयोगकर्ता द्वारा HTTP request भेजने से लेकर browser द्वारा पहला byte लोड करने तक कितना समय लगता है
  • इसका उपयोग website responsiveness के संकेतक के रूप में होता है
  • ज़रूरत हो तो time to first byte (TTFB) metric जैसी अतिरिक्त सीखने की लिंक दी जा सकती है

• tone में एकरूपता

  • लेख का tone चाहे conversational हो या formal, उसे एक चुनकर लगातार बनाए रखना चाहिए
  • अगर एक वाक्य बहुत बोलचाल के अंदाज़ में शुरू होकर अकादमिक भाषा में बदल जाए, तो यह पाठक को भ्रमित कर सकता है या उसके ध्यान को मुख्य बात से हटा सकता है
  • उदाहरण वाक्य को इस तरह बदला जा सकता है कि उसका tone एक जैसा रहे: “मैं नए framework को लेकर शुरुआत में उत्साहित था, लेकिन मैं अपनी इच्छित metrics पकड़ नहीं पाया”

jargon, cliché और visual structure को सँवारना

• jargon और cliché से बचें

  • business jargon में “deep dive”, “low-hanging fruit” जैसे प्रयोग आते हैं, और दूसरे लेखों में baseball रूपकों जैसे cliché भी अक्सर मिलते हैं
  • jargon यह मानकर चलता है कि पाठक उस आंतरिक समूह का हिस्सा है जो ये अभिव्यक्तियाँ इस्तेमाल करता है
  • जिन पाठकों की पहली भाषा English नहीं है, या जो baseball संस्कृति से परिचित नहीं हैं, उनके लिए jargon और cliché लेख का पीछा करना कठिन बना सकते हैं
  • “tl;dr, if you can hack something together by EOD…” में abbreviation और technical slang हैं, और यह अनुरोध जैसा भी नहीं लगता
  • “Can you deliver a prototype by the end of today?” आवश्यक परिणाम और समय-सीमा को सीधे पूछने वाला स्पष्ट अनुरोध बन जाता है

• whitespace और formatting का उपयोग

  • whitespace तकनीकी दस्तावेज़ों में महत्वपूर्ण है, और ब्लॉग पोस्ट व ईमेल में भी प्रभावी होता है
  • लंबे पैराग्राफ, खासकर कंप्यूटर स्क्रीन पर, पढ़ने में कठिन होते हैं और पाठक का ध्यान टूट सकता है
  • पेज को दृश्य रूप से विभाजित करने से मुख्य बिंदु ढूँढ़ना आसान होता है
  • लंबे पैराग्राफ को कई छोटे पैराग्राफ में बाँटें
  • उपयोगी subheadings से संरचना बनाएँ, ताकि पाठक अपनी रुचि वाले section पर जा सकें
  • संबंधित बिंदुओं को सूची के रूप में लिखें
  • reference documents जैसे बहुत-सी जानकारी देने वाले मामलों में, सूची की तुलना में table अधिक उपयुक्त हो सकती है
  • सरसरी नज़र से पढ़ने वाले पाठक भी मुख्य बात पकड़ सकें, इसके लिए bold का उपयोग करें

संपादन का दर्शन

• संपादन के दर्शन को दो बातों में समेटा जा सकता है
  • adverb, jargon, cliché और hedge पर निर्भर हुए बिना, जो ठीक-ठीक कहना है वही कहें
  • सभी अनावश्यक शब्द हटा दें
• ये दो सिद्धांत अपनी लिखाई सुधारने और दूसरों के लेखन का मूल्यांकन करने के लिए एक ढाँचा बनते हैं
• अभ्यास के साथ आपका अपना style और पसंद विकसित होती है, और यदि आपको कारण पता है, तो कुछ सिफारिशों से हटना भी ठीक है
• संपादन का उद्देश्य नियमों का बिना सोचे-समझे पालन करना नहीं, बल्कि भाषा-प्रयोग के प्रति सजग रहना और अपने संदेश के अनुरूप सही चुनाव करना है

[GN⁺]

Hacker News की राय

• यह लेख लिखने वाला मैं ही हूँ। खुशी और सम्मान की बात है कि यह इतने लोगों से जुड़ा। लेख लिखने के बाद अपनी जिज्ञासा के चलते मैं खुद software engineer बन गया, और कुछ साल काम करने के बाद मुझे ऐसी भूमिका की कमी महसूस हुई जिसमें writing का हिस्सा बड़ा हो अगर आप किसी बेहतरीन technical writer, developer advocate, या communication expertise और technical capability को मिलाने वाली भूमिका की तलाश में हैं, तो बताइए। website form (https://evaparish.com/contact) या LinkedIn के जरिए संपर्क कर सकते हैं

  • इस लेख से मुझे वाकई बहुत कुछ मिला। लगता है यह मुझे और संक्षिप्त व स्पष्ट लिखने, और बात को बेहतर समझाने में मदद करेगा हालांकि “I really got a lot out of the article.” लिखने के बाद मैंने सोचा कि क्या यह वाक्य अनावश्यक है, स्पष्ट है, और क्या यही बात मैं ठीक-ठीक कहना चाहता था। आखिर में लगा कि हाँ, मैं यही कहना चाहता था और अगले वाक्य में उसे विस्तार से बताया, लेकिन आप इसे कैसे देखते हैं, जानना चाहूँगा
  • Jean-luc Doumont के lecture/workshop Clear, accurate, concise writing में सुनी हुई writing advice बहुत याद आई
  • उदाहरण में HTTP को बिना समझाए इस्तेमाल करना काफी मजेदार लगा। जानना चाहूँगा कि क्या यह जानबूझकर किया गया joke था

• technical documents पढ़ते समय सबसे ज्यादा खटकने वाली चीजों में से एक है, जब पाठक को अभी तक introduce न किए गए acronyms दिखाई देते हैं। project documents में कई जगह यह बार-बार होता है, और कुछ सालों में responsible लोग बदल जाएँ तो स्थिति यहाँ तक पहुँच जाती है कि कोई नहीं जानता कि कोई खास acronym किसका संक्षेप है मैंने सचमुच कई बार ऐसी अजीब स्थिति देखी है जहाँ कोई team ABC नाम की service develop और maintain करती है, लेकिन team में किसी को नहीं पता कि ABC किसका acronym है। ऐसे में नया नाम चुनने और संबंधित documents सभी update करने के काम से बचने के लिए ABC को proper noun की तरह treat करके आगे बढ़ जाते हैं नकली उदाहरण: CDIS के लिए access token पाने के लिए के DMC पर जाएँ, left sidebar में "CDIS" item पर click करें और token copy करने के लिए "Generate Access Token" दबाएँ मैं इसे यूँ पढ़ना चाहूँगा: Customer Data Indexing Service(CDIS) के लिए access token पाने के लिए के Data Management Console(DMC) पर जाएँ, left sidebar में "CDIS" item पर click करें और token copy करने के लिए "Generate Access Token" दबाएँ

  • बेहतर रूप यह है: [Get" rel="nofollow">https://dsc.prod.ex.com/gettoken">Get](