वर्धमान प्रकाशन युग में गैर-ब्रेकिंग स्पेस (Non-breaking Spaces) पर पुनर्विचार

Question

सभी को नमस्ते, मैं डिजिटल प्रकाशन के युग में गैर-ब्रेकिंग (no-break) स्पेस (U+00A0) पर चर्चा करना चाहता/चाहती हूँ।

मैं एक ऐसे देश में काम करता/करती हूँ जो आधिकारिक रूप से फ्रेंच और अंग्रेज़ी द्विभाषी है। अंग्रेज़ी-भाषी देशों में, गैर-ब्रेकिंग और आधा स्पेस दुर्लभ होते हैं। आप शायद 1·Chronicles के भागों के बीच एक गैर-ब्रेकिंग स्पेस पा सकें।

इसके विपरीत, फ्रेंच-भाषी क्षेत्रों के अधिकांश अनुवादक फ्रेंच स्पेसिंग नियमों का पालन करना चाहते हैं। फ्रेंच-भाषी दुनिया में, 2 चिह्नों (; ! : ? « ») से पहले/आसपास स्पेस आवश्यक होते हैं। बड़ी संख्याओं में हज़ारों के विभाजक के रूप में गैर-ब्रेकिंग स्पेस अक्सर उपयोग किए जाते हैं, जैसे 1·000 (Number Settings - Thousands Separator रीसेट हो जाता है - #3 by jeffh)। प्रकाशन मानक भिन्न-भिन्न होते हैं, लेकिन इस मामले के आदर्श उम्मीदवार सामान्य no-break space (U+00A0) और narrow no-break space (U202F) हैं। यह बंद करने वाले पंक्ति चिह्न (closing punctuation mark) को अगली पंक्ति में धकेलने से रोकता है, विशेष रूप से बहु-स्तंभ लेआउट में। ये स्पेस टेक्स्ट को दुनिया के कंप्यूटरों पर प्रवाहित रहने देते हैं। मानक स्पेस (U+0020), thin space (U+2009), और hair space (U+022A) की चौड़ाई भिन्न होती है, लेकिन ये आवश्यक अनाथ संरक्षण (orphan protection) प्रदान नहीं करते।

कुछ टूल्स गैर-ब्रेकिंग स्पेस को दृश्य रूप से एक धुंधला बिंदु या ग्रे बॉक्स के रूप में प्रस्तुत करने का विकल्प चुनते हैं। Paratext स्वतः गैर-ब्रेकिंग स्पेस (U+00A0) को एक विशाल टिल्ड (~, U+007E) से बदल देता है। वर्तमान संस्करणों में, 00A0 दर्ज करके ALT-X दबाने पर, जो गैर-ब्रेकिंग स्पेस होना चाहिए, उसे साधारण (0020) स्पेस से बदल दिया जाता है, जो पूर्ण रूप से गलत है। यह विशाल टिल्ड हमारे अनुवादकों के लिए बहुत विचलित करने वाला है, और इसलिए अधिकांश समय, फ्रेंच-भाषी अनुवादकों को निर्देश दिया गया है कि वे या तो साधारण स्पेस का उपयोग करें या पंक्ति चिह्नों से पहले स्पेस का उपयोग न करें, इस समझ के साथ कि टाइपसेटर छापने से ठीक पहले उनके निर्णयों के अनुसार स्पेस को मानकीकृत कर देंगे। मुझे पूर्ण रूप से पता है कि प्रीव्यू मोड में विशाल टिल्ड्स को गैर-ब्रेकिंग स्पेस से बदल दिया जाता है, और Print Draft परिवर्तनों या ptxPrint के माध्यम से बदला जा सकता है। एक रचनात्मक तकनीकी व्यक्ति PTX print को कॉन्फ़िगर कर सकता है कि ऐसे चरों से पहले स्पेस सम्मिलित करे, लेकिन तब वे Paratext में बिल्कुल नहीं दिखेंगे।

Paratext दस्तावेज़ीकरण से:

इसके कारण, Paratext अब गैर-ब्रेकिंग स्पेस के उपयोग का समर्थन नहीं करता है। यदि आप अपने टेक्स्ट में गैर-ब्रेकिंग स्पेस का उपयोग करना चाहते हैं, तो आपको गैर-ब्रेकिंग स्पेस की जगह टिल्ड दर्ज करना चाहिए। इन्हें टाइपसेटिंग के समय गैर-ब्रेकिंग स्पेस में परिवर्तित किया जा सकता है। टेक्स्ट में दर्ज किए गए टिल्ड्स को Preview दृश्य में गैर-ब्रेकिंग स्पेस के रूप में प्रदर्शित किया जाता है।

यदि यह कुछ दुर्लभ होता (जैसे अंग्रेज़ी में है), तो मैं चिंतित नहीं होता/होती, लेकिन यह फ्रेंच-भाषी टेक्स्ट के लगभग हर अनुच्छेद में आता है। मेरी चिंता यह है कि 1) टिल्ड्स उन अनुवादकों के लिए विचलित करने वाले हैं जो मानक दृश्य में अपना समय बिताते हैं, और उन लोगों के लिए जो उनके कंधे के ऊपर से पढ़ रहे हैं, और 2) कि डिजिटल प्रकाशन और साझा करने के इस युग में यह प्रतिबंध टिक नहीं पाता।

तकनीकी रूप से,~एक~लोग~टिल्ड्स~के~मध्यम~से~प्रकाशित~हो~सकते~हैं। क्षेत्र स्टाफ की टिल्ड्स के प्रति प्रतिक्रिया, जो टाइपसेटिंग तक गैर-ब्रेकिंग स्पेस को नज़रअंदाज कर देती है, अब व्यवहार्य नहीं है, क्योंकि टेक्स्ट केवल टाइपसेटर द्वारा छापने के लिए तैयार नहीं किए जाते हैं। व्यक्तिगत पुस्तकें स्थानीय स्तर पर प्रकाशित होती हैं, डिजिटल संस्करण DBL में डाले जाते हैं और उपलब्ध कराए जाते हैं, और Scripture Apps बनाए जाते हैं। इसका मतलब है कि Paratext संस्करण में “अंतिम” स्पेसिंग की उपस्थिति बढ़ती हुई महत्वपूर्ण हो रही है, और Paratext अभी भी इसका “वास्तविक” समर्थन नहीं करता। (मैंने आज ही खोजा है कि narrow no-break space (U202F) का कोई दृश्य संकेतक नहीं है, लेकिन कृतज्ञता के साथ यह टिल्ड नहीं बनता।) U+202F का असंगत प्रदर्शन/संभाल, जो संकीर्ण होना चाहिए, यहाँ चर्चा की गई है (Deletion of Unicode 202F ("narrow no break space") in project)

LibreOffice गैर-ब्रेकिंग स्पेस को सामान्य स्पेस से अलग करने के लिए एक ग्रे बॉक्स का उपयोग करता है। Word के Show/Hide फीचर गैर-ब्रेकिंग स्पेस के लिए एक खुला वृत्त और सामान्य स्पेस के लिए एक केंद्रित बिंदु का उपयोग करता है।

क्या Paratext डेवलपर्स इंटरफेस में टिल्ड को छोड़ने और कुछ अधिक पठनीय और कम विचलित करने वाले का उपयोग करने पर विचार करेंगे? क्या इसके लिए USFM में कोई परिवर्तन आवश्यक होगा, या केवल Paratext में? अनुवादक पहले से ही अपने टेक्स्ट में USFM मार्कर जैसे धूसर मेटाडेटा के उपयोग के लिए उपयोग किए जाते हैं। मानक दृश्य में एक धुंधला ग्रे बिंदु · विशेष स्पेस और सामान्य स्पेस को अलग करने में सहायक होगा, सही है? ग्रे वर्गों के साथ जाना दोनों गैर-ब्रेकिंग प्रकृति और लंबाई दिखाएगा, जो मुझे लगता है कि इसीलिए LibreOffice ने उन्हें चुना। यह आशा है कि यह पार-सांस्कृतिक संगतता के लिए एक बड़ी जीत होगी, उम्मीद है कि फ्रेंच-भाषी दुनिया में काम करने वाला कोई अन्य व्यक्ति भी अपना मत दे सके। @jeffh @dhigby @anon023887 ?

मुझे इस पोस्ट (Non-breaking space issues) से समझ में आया है कि टिल्डिफिकेशन (tildefication) को Internet Explorer के एक वैकल्पिक समस्या से लड़ने के लिए पेश किया गया था। आज भी, एक वेबपेज में दो लगातार स्पेस के लिए आवश्यक है कि कम से कम एक को NBSP में परिवर्तित किया जाए। हाँ, स्पेस को दृश्य रूप से अलग करना कठिन है, लेकिन टीमों को उन्हें मानकीकृत करना पड़ता है।
~ Matthew_Lee
Language Technology Consultant
SIL Cameroon

बुरी तरह से, Paratext सहायता गैर-ब्रेकिंग स्पेस को एक ऐसी बला के रूप में मानती है जिसे नष्ट किया जाना चाहिए (नीचे देखें)।

मेरे टेक्स्ट में स्पेस की जगह टिल्ड्स क्यों दिखते हैं?
गैर-ब्रेकिंग स्पेस वे चर हैं जो स्पेस जैसे दिखते हैं लेकिन जो अनुमति नहीं देते…
गैर-ब्रेकिंग स्पेस वे चर हैं जो स्पेस जैसे दिखते हैं लेकिन जो उस स्थान पर पंक्ति टूटने की अनुमति नहीं देते। गैर-ब्रेकिंग स्पेस वाले टेक्स्ट को खोलने पर, यदि आप पाते हैं कि वे स्पेस टिल्ड चरों (~) से बदल दिए गए प्रतीत होते हैं, तो यह जानबूझकर है। Paratext उन्हें टिल्ड्स के रूप में प्रदर्शित करके गैर-ब्रेकिंग स्पेस को दृश्यमान बनाता है।
इसके बारे में मुझे कम से कम क्या जानना चाहिए?
Paratext के पहले संस्करणों ने कभी-कभी गलती से जहां सामान्य स्पेस की आवश्यकता थी, वहां गैर-ब्रेकिंग स्पेस सम्मिलित कर दिए। इसलिए, यदि आप टेक्स्ट के किसी ऐसे स्थान पर एक कभी-कभी टिल्ड देखते हैं जिसमें आप पूर्ण रूप से निश्चित हैं कि गैर-ब्रेकिंग स्पेस की आवश्यकता नहीं है, तो आप बस टिल्ड को स्पेस से बदल सकते हैं।
यदि मैं समस्या को एक बार में सही करना चाहता/चाहती हूँ तो क्या करूँ?
यदि आपने जानबूझकर अपने टेक्स्ट में कोई गैर-ब्रेकिंग स्पेस या टिल्ड्स सम्मिलित नहीं किए हैं और इसलिए सभी गैर-ब्रेकिंग स्पेस और टिल्ड्स को हटाना चाहते हैं, तो Option 1 के निर्देशों का पालन करें। यदि आप पूर्ण रूप से निश्चित नहीं हैं कि टिल्ड्स या गैर-ब्रेकिंग स्पेस जानबूझकर सम्मिलित किए गए थे या नहीं, तो उन्हें हटाने से पहले अपने CAP सहायता व्यक्ति से संपर्क करें, अन्यथा आपको उन्हें मैन्युअल रूप से पुनः दर्ज करना पड़ सकता है।

             Option 1 (To get rid of all no-break spaces and tildes):
             
                Click the tab of your project to make it the active tab.
                From the Tools menu, point to Advanced and then select Replace No-Break Spaces With Normal Spaces.
                Read the warning message and click Yes if you are sure you wish to continue.

        If your project has been following the USFM manual and so has been manually inserting tildes either to represent no-break spaces or for some other function, follow the instructions in Option 2. Doing this sooner rather than later prevents Paratext from inserting any more occasional unwanted tildes.

             Option 2 (To get rid of no-break spaces, but keep all tildes):
             
                Click the tab of your project to make it the active tab.
                From the Tools menu, point to Advanced and then select Replace No-Break Spaces With Normal Spaces But Keep Tildes.
                Read the warning message and click Yes if you are sure you wish to continue.
        
         See also:
        
          Important information about no-break spaces and tildes

English से मशीन-अनुवादित मूल दिखाएं

Answer 1

हाँ, मैं Matthew_Lee के साथ सहमत हूँ कि यह एक महत्वपूर्ण मुद्दा है, विशेष रूप से फ्रेंच-भाषी दुनिया में। मेरी विश्लेषण में कई बातें हैं जो मैं उल्लेख करना चाहता हूँ, लेकिन मैं इस पोस्ट के नीचे एक सारांश (TLDR) देने की कोशिश करूँगा।

थोड़ा ऑनलाइन शोध कुछ दिलचस्प बातें दिखाता है, जो वास्तव में "विषय से बाहर" नहीं हैं:

और कुछ हास्यपूर्ण विफलताएँ (जहाँ वे स्पष्ट रूप से सामान्य स्पेस का उपयोग कर रहे थे - जो इस मामले में टूट गया था):

यह बिल्कुल वही है जिससे हम बचना चाहते हैं - बिंदु चिह्नों के टुकड़े जो उनके संबंधित पाठ से जुड़े नहीं हैं। इसलिए, यदि हम बिंदु चिह्नों को अलग करने के लिए किसी प्रकार के स्पेस चर का उपयोग करने जा रहे हैं, तो हमें हमेशा किसी प्रकार का non-breaking space (अटूट स्पेस) उपयोग करना होगा।

मुख्य दो विकल्प पूर्ण No-Break Space (NBSP, U+00A0) हैं, या Narrow No-Break Space (NNBSP, U+202F), जिनकी परिभाषाएँ Unicode मानक में पाई जा सकती हैं, https://unicode.org/charts/PDF/U0090.pdf और https://unicode.org/charts/PDF/U2000.pdf पर, क्रमशः:

जैसा कि आप देख सकते हैं, NNBSP की परिभाषा कहती है कि यह आमतौर पर एक thin space की चौड़ाई होती है, जिसे उसी चार्ट में इस प्रकार परिभाषित किया गया है:

तो NNBSP आमतौर पर एक em का पाँचवाँ हिस्सा (0.2em) होगा। एक सामान्य स्पेस या NBSP कितना बड़ा है? ये माप फॉन्ट-निर्भर हैं, लेकिन Charis SIL फॉन्ट के साथ एक अनुमानित गणना दिखाती है कि स्पेस और NBSP चर लगभग 0.34em हैं। NNBSP लगभग 0.22em है। यह एक महत्वपूर्ण अंतर है, और यदि आप बिंदु चिह्नों के चारों ओर NBSP (या एक अस्थायी उपाय के रूप में एक नियमित स्पेस, जिसका नुकसान यह है कि यह पंक्तियों के बीच टूट सकता है) का उपयोग करते हैं, तो मुझे पता है कि टाइपसेटर्स कहेंगे कि वह स्पेस बहुत बड़ा है। NNBSP का उपयोग करना काफी मदद करता है, और PTXprint में इस तरह की परिवर्तनों के साथ इसे काफी आसानी से किया जा सकता है PrintDraftChanges.txt में:

' *:'  >    '\u202f:'     # Place non-breaking thin space before colon
'« *' >    '«\u202f'     # Place non-breaking thin space after opening guillemets
' *»' >    '\u202f»'     # Place non-breaking thin space before closing guillemets
'‹ *' >    '‹\u202f'     # Place non-breaking thin space after opening guillemets
' *›' >    '\u202f›'     # Place non-breaking thin space before closing guillemets

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

image945×67 35 KB

ध्यान दें कि आप देख सकते हैं कि ये बस सामान्य स्पेस हैं यदि आप ज़ूम और/या पैन आकार को ठीक से समायोजित करते हैं, क्योंकि वे पंक्ति के बीच टूटने की अनुमति देंगे, इस तरह:

image755×114 48.8 KB

लेकिन ऊपर दिए गए परिवर्तन इन दोनों मामलों को ठीक से संभालने में सक्षम होने चाहिए, और टाइपसेटिंग के लिए NNBSP डालना चाहिए।

एक समान तरीके से, आप अपने SAB परियोजनाओं में परिवर्तन नियम डालना चाहेंगे, यह सुनिश्चित करने के लिए कि आपकी Scripture ऐप्स स्पेस को उचित रूप से संभालें। नमूना नियमों के लिए इस पोस्ट को देखें: https://community.scripture.software.sil.org/t/suggestions-for-changes-gallery/590/3.

ध्यान दें कि इस पोस्ट में दिए गए नियम स्पेस या no-space को ऊपर दिए गए नियमों की तरह इतने शानदार तरीके से संभालते नहीं हैं, लेकिन आप उन्हें ऊपर उपयोग किए गए " *" जैसे चालों के साथ समायोजित कर सकते हैं।

और Paratext पर आने से पहले एक और बिंदु… हाल की टाइपसेटिंग नौकरियों में हमने वास्तव में बिंदु चिह्नों के चारों ओर स्पेस के रूप में em का दसवाँ हिस्सा (0.1em) उपयोग किया है, यानी NNBSP से छोटा। यहाँ वह बिंदु चिह्न परिभाषा है जिसका हमने उपयोग किया था:

\catcode`\:=\active \def:{\unskip\kern0.1em\char`\:{}} % colon

नोट: यह XeTeX में किया गया था, लेकिन PTXprint के साथ भी ऐसा ही किया जा सकता है। मुझे लगता है कि आप इसे Advanced टूल टैब पर उपलब्ध ptxprint-mods.tex कॉन्फ़िगरेशन फ़ाइल में परिभाषित करना चाहेंगे। यह बिंदु चिह्नों के चारों ओर एक काफी न्यूनतम स्पेस देता है, जैसा कि इस नमूने में देखा गया है:

image752×102 11.5 KB

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

निष्कर्ष (TLDR): तो इसका Paratext के लिए क्या मतलब है?

यदि टीम पाठ में अपने बिंदु चिह्नों को अलग करने के लिए नियमित स्पेस का उपयोग करती है, तो कभी-कभी यह Paratext में उनके स्क्रीन पर गलत रूप से प्रकट होगा (यानी बिंदु चिह्नों जो उनके पाठ से उचित रूप से जुड़े नहीं हैं, जैसा कि ऊपर दिखाया गया है), जो ध्यान भटकाने वाला है लेकिन दुनिया का अंत नहीं है। इस मामले में, दायित्व टाइपसेटर या ऐप बिल्डर पर है कि वे उन नियमित स्पेस को उचित रूप से बदलें। दुर्भाग्य से, यदि यह रूप DBL में डाला जाता है (जो बहुत संभावना है), तो YouVersion जैसी ऐप्स समस्याओं का सामना करने वाली हैं, क्योंकि वे प्रसिद्ध रूप से उन स्पेस को उचित रूप से संभालते नहीं हैं।

बिंदु चिह्नों को अलग करने के लिए छोटे और छोटे no-break spaces की इस प्रवृत्ति को देखते हुए (पहले 0.2em पर NNBSP, फिर PTXprint के साथ 0.1em पर मैनुअली टाइपसेटिंग) जो मैंने अपनी टाइपसेटिंग परियोजनाओं में देखा है, मैं लगभग हमेशा सिफारिश करता हूँ कि टीम Paratext में अपने बिंदु चिह्नों के चारों ओर कोई स्पेस न डालें, और फिर बस टाइपसेटिंग या ऐप बिल्डिंग पर भरोसा करें कि वे उन बिंदु चिह्नों के चारों ओर सही काम करें। इसका मतलब यह है कि जब पाठ DBL में डाला जाता है, तो YouVersion के पास कोई लटका हुआ बिंदु चिह्न नहीं होगा। (उसके पास बिंदु चिह्नों के चारों ओर स्पेस भी नहीं होंगे, लेकिन मेरे विचार से यह एक कम समस्या है।)

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

यह पोस्ट उतना समाधान प्रस्तावित करने के रूप में नहीं है जितना कि अधिक पृष्ठभूमि और जानकारी प्रदान करने के रूप में है। मुझे Paratext में इस टिल्ड / NBSP चीज़ के काम करने का तरीका वास्तव में पसंद नहीं है, और सहमत हूँ कि इसे बदलना चाहिए। ऐसा लगता है कि Paratext को यह मानना चाहिए कि पाठ में हर चर को सतही रूप से लेना चाहिए, चाहे वह टिल्ड, NBSP या NNBSP हो। और उन्हें (सूक्ष्म रूप से) देखने का एक तरीका अच्छा होगा। क्या दो या अधिक स्पेस को स्वतः संयोजित किया जाना चाहिए (@anon942452 के जवाब में)? शायद यदि वे समान चर हैं? इससे स्वचालित Paratext स्पेसिंग फिक्स की अनुमति मिलती रहेगी, लेकिन इससे बचने के लिए कुछ विकल्प भी प्रदान करेगा। और सभी legacy परियोजनाओं के साथ निपटने का एक तरीका भी आना होगा जो non-breaking spaces के लिए टिल्ड्स का उपयोग करती हैं, शायद बस एक रूपांतरण, उन्हें सभी को NBSP में रूपांतरित करने के लिए, एक बार जब Paratext में इसका उचित रूप से निपटारा हो जाता है।

वैसे भी, थोड़ा और विचार के लिए भोजन…

English से मशीन-अनुवादित मूल दिखाएं

Comments

दक्षिण-पूर्व एशिया के कुछ राष्ट्रीय भाषाएँ वाक्यांशों के बीच स्पेस का उपयोग करती हैं और शब्दों के बीच नहीं। इन लिपियों का उपयोग करने वाली कुछ अल्पसंख्यक भाषाओं ने प्रत्येक शब्द के बीच सामान्य स्पेस और वाक्यांश ब्रेक पर एक चौड़ा स्पेस का उपयोग करने का चयन किया है। यदि Paratext में इन चौड़े-स्पेस वाक्यांश ब्रेक के लिए EM SPACE (\u2003) का उपयोग किया जाता है, तो Character और Punctuation Inventories EM SPACE को बिंदु के बजाय शब्द-गठन चरित्र के रूप में मानते हैं, जिससे सही अनुक्रमों की जांच करना असंभव हो जाता है। मैंने इसे PTXS-31753 के रूप में रिपोर्ट किया है।

जब jeffh अनुवादकों को Paratext से फ्रेंच स्पेस पूरी तरह से बाहर रखने की सिफारिश करते हैं, तो वे Paratext में पाठ के अस्पष्ट रूप से संरचना/अर्थ को चिह्नित करने में मदद कर रहे हैं, एक कठोर प्रस्तुति की कीमत पर। मैं Paratext के भीतर EM SPACE के बजाय कॉमा के उपयोग की सिफारिश करने पर भी ऐसा ही करता हूँ। लेकिन उपयोगकर्ता दोनों सुझावों के खिलाफ आगे बढ़ने के लिए सही हैं; मैं भी Microsoft Word में WYSIWYG को WordStar डॉट कमांड्स से बहुत अधिक पसंद करता हूँ जिन्हें मैंने अपने पहले कंप्यूटर पर उपयोग किया था।

मुझे Paratext को एक "Show Invisible Characters" विकल्प जोड़ते हुए देखना पसंद होगा, जो, उदाहरण के लिए, स्पेस चरित्रों को एक ग्रे बॉक्स के रूप में दिखाएगा। यह "Show Invisible Characters" उन भाषाओं के लिए अत्यंत लाभदायक होगा जो प्रत्येक शब्द के बीच Zero Width Space (\u0200b) टाइप करती हैं। वर्तमान में Paratext की सिफारिश है कि प्रत्येक शब्द के बीच एक स्लैश (/) टाइप किया जाए। यह स्लैश फिर (घृणित रूप से) Preview व्यू के अलावा सभी में दिखाई देता है।

मुझे आश्चर्य है कि क्या फ्रेंच-भाषी क्षेत्र एक फॉन्ट खोज सकते हैं जो या तो (1) ~ को बहुत कम आक्रामक बना दे या (2) संदर्भ के अनुसार बिंदुओं के चारों ओर स्पेस को स्वतः समायोजित कर दे।

आशीर्वाद,
LivingField

English से मशीन-अनुवादित मूल दिखाएं

---

कभी-कभी Paratext को कस्टमाइजेशन अनुरोधों को समायोजित करना एक नुकसान हो सकता है। यह विशेष रूप से तब सच है जब कस्टमाइजेशन अन्य सॉफ्टवेयर में समर्थित न हो या जब यह उन विकल्पों की अनुमति देता हो जो वाणिज्यिक सॉफ्टवेयर की दिशा के विरुद्ध हों। भाषा समुदाय तब Paratext के बाहर अपने भविष्य के विकास के लिए मृत सड़कों (dead ends) का चयन करते हैं। (जो भी हो, यह अन्य स्थितियों में बहुत सहायक भी रहा है, मुद्दे बस जटिल हैं और सावधानी से विचार की आवश्यकता है।)

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

आशीर्वाद,

English से मशीन-अनुवादित मूल दिखाएं

Answer 2

Matthew_Lee, आपकी सहायक और सूचनात्मक ईमेल के लिए धन्यवाद। मेरे पास प्रस्तावित कोई समाधान नहीं है, लेकिन मुझे इस विषय में बहुत रुचि है और आपकी विस्तृतता से मैंने और अधिक सीखा। विशेष रूप से RTL और LTR अदृश्य चरों के साथ मैं संघर्ष करता/करती हूँ, जो हमारे जटिल लिपियों को प्रभावित करते हैं। यदि एक तरीका हो जिससे सभी अदृश्य चरों को थोड़ा दृश्यमान बनाया जा सके (या शायद ctrl कुंजी के साथ दृश्यता चालू/बंद की जा सके), तो यह उन कठिन स्थितियों को हल करने में सहायक हो सकता है जिनमें हम खुद को पाते हैं। यह दृष्टिकोण सामान्य गैर-ब्रेकेबल स्पेस को Paratext में उपयोग के लिए व्यवहार्य भी बना सकता है, हालाँकि मुझे प्रोग्रामिंग पक्ष पर इसके उपयोग के लिए अन्य संभावित बाधाओं के बारे में कोई जानकारी नहीं है।

आशीर्वाद,

English से मशीन-अनुवादित मूल दिखाएं

Answer 3

प्रिय Matthew_Lee, इसे उठाने के लिए धन्यवाद। मैं उत्तरी अमेरिकी First Nations भाषाओं में काम करता/करती हूँ जो एक गैर-रोमन लिपि (Canadian Syllabics) का उपयोग करती हैं और इस लिपि का उपयोग करने वाले कई प्रमुख वर्तनी प्रणाली (orthographies) विभिन्न चौड़ाई (तीन चौड़ाई) के सफेद स्पेस का उपयोग मोर्फेम और शब्द सीमाओं को संकेत देने के लिए करती हैं। सामान्य शब्द स्पेस 0020 पसंदीदा syllabic फॉन्ट में काफी चौड़ा होता है, जो Paratext में ठीक से काम करता है। लेकिन narrow-no-break-space (U+202F) सामान्य शब्द स्पेस की चौड़ाई का 1/3 होता है। इस स्पेस का उपयोग हमारी भाषा में भी महत्वपूर्ण है–इसे शब्दों के भीतर मोर्फेम सीमा के रूप में उपयोग करने की आवश्यकता होती है और (फ्रेंच में किए जाने की तरह) वाक्यों के अंत से पंक्ति चिह्नों को अलग करने के लिए। अंत में, कई स्थितियों में गैर-ब्रेकिंग स्पेस की तीसरी चौड़ाई आवश्यक होती है। वर्षों से, जिन भाषा समुदायों के साथ हमने काम किया है, उन्होंने प्रिफिक्स और शब्द तनों के बीच गैर-ब्रेकिंग स्पेस प्रदान करने के लिए दो narrow no-break-spaces (U+202F U+202F) का क्रमिक उपयोग किया है, जो पंक्तियों के अंत में अनाथों को रोकता है और तने की शुरुआत के लिए एक दृश्य संकेत प्रदान करता है। इनकी चौड़ाई मानक शब्द स्पेस के 2/3 के बराबर होती है।

दुर्भाग्यवश, Paratext 7 के बाद से, एक paratext एल्गोरिदम है जो क्रम में किसी भी दो समान सफेद स्पेस चरों को हटा देता है और उन्हें एक से बदल देता है। हमें एक क्लडजी (kludgy) वर्क-अराउंड बनाना पड़ा जिसमें एक keyman कीबोर्ड बनाया गया जो zero-width non-breaking space (U+200D) सम्मिलित करता है, ताकि Paratext हमारे जानबूझकर double-thin-space (U+202F U+202F) को केवल एक से बदल न दे।

जब हम अपनी पवित्र ग्रंथों को DBL में निर्यात करते हैं, तो यह अनुक्रम स्वीकार्य नहीं था, इसलिए हमें पहले एक रूपांतरण कार्यक्रम चलाना पड़ता है जो सभी अनुक्रमों (U+202F U+200D U+202F) को एक “मानक” गैर-ब्रेकिंग स्पेस (Paratext में, “टिल्ड”, जो U+00A0 बन जाता है) से बदल देता है।

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

सincerely, anon942452 J

English से मशीन-अनुवादित मूल दिखाएं

Comments

आधुनिक वेब तकनीकें आमतौर पर पूछे बिना डुप्लिकेट स्पेस को संपीड़ित (compress) कर देती हैं, लेकिन अक्सर वे स्पेसिंग के कई प्रकारों के बीच वैकल्पिकता की अनुमति देती हैं। इसी कारण से, वेब डिज़ाइनर लंबे समय से इंडेंट सेट करने के बजाय स्पेस और nbsp को वैकल्पिक रूप से उपयोग करके स्पेसिंग का दुरुपयोग कर रहे हैं। @anon942452 ने एक विधि खोजी है जो स्वचालित कचरा सफाई को उसी तरह ओवरराइड करने के काम आती है।

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

मेरी उम्मीद है कि Paratext सभी प्रकार के स्पेस का समर्थन करना सीख सके, ताकि Paratext प्रोजेक्ट स्वर्ण मानक (gold standard) बन सके।

पहली चुनौती यह है कि इन स्पेस को स्वीकार करना हो और उन्हें DBL और डिजिटल/प्रिंट प्रकाशन तक जाने देना हो। शायद मैं एक आशावादी हूं, लेकिन मोबाइल ऐप्स, inDesign, और HTML की कोई समस्या नहीं होनी चाहिए क्योंकि सुझाए गए फॉन्ट्स में ये यूनिकोड ग्लिफ्स हैं। TeX (PTXPrint) को प्री-प्रोसेसिंग का थोड़ा सा काम चाहिए होगा, लेकिन TeX में इसे प्रबंधित करने के लिए टूल्स मौजूद हैं। अगर YouVersion जैसे डाउनस्ट्रीम टूल्स को एडवांस्ड स्पेस/ब्रेक्स का उपयोग करना सीखना पड़े, तो वह एक चर्चा के लायक है।

दूसरी चुनौती यह है कि Paratext में एडवांस्ड स्पेसिंग के साथ काम करना आसान बनाना। मुझे ग्रे वर्ग (grey squares) देखकर नॉन-ब्रेकिंग स्पेस के लिए बहुत खुशी होगी। पंक्चुएशन टूल बस काम कर सकता है क्योंकि यह संयोजनों के लिए यूनिकोड मान पहले से ही दिखाता है।

English से मशीन-अनुवादित मूल दिखाएं

Answer 4

मेरा मानना है कि एक प्रारंभिक प्रस्ताव के रूप में, हम Paratext से Project View मेनू में “Show hidden formatting” विकल्प जोड़ने का अनुरोध कर सकते हैं। जब आप Word में ऐसा करते हैं, तो तीन स्पेस, तीन NBSP और तीन NNBSP (202F) की श्रृंखला के लिए आपको निम्नलिखित मिलता है:

LibreOffice Writer में आपको यह मिलता है:

LO Writer NBSP नहीं दिखाता है, और न ही वे दोनों NNBSP दिखाते हैं। स्वर्ण मानक बनने के लिए, हमें ऐसा करना होगा। लेकिन आप यह भी नहीं चाहते कि हर संभावित छिपी हुई फॉर्मेटिंग के लिए एक अलग प्रतीक हो, तो क्या हम चर कोड दिखाने की ओर बढ़ेंगे, सिवाय कुछ प्रमुख चरों जैसे स्पेस और NBSP (जिनके पास एक प्रतीक होगा) के, शायद एक छोटे डायगोनल पैटर्न में? क्या ऐसा कुछ होगा:

image772×660 19.4 KB

मेरा मानना है कि अलग रंग में छिपी हुई फॉर्मेटिंग दिखाना उपयोगी है। Matthew_Lee ग्रे सुझाते हैं, LO Writer नीला उपयोग करता है, और Word बस काला उपयोग करता रहता है। मुझे भी ग्रे का विचार पसंद है, लेकिन ट्विस्ट यह होगा कि सही शेड का ग्रे प्राप्त करना, ताकि वह दिखाई दे लेकिन सूक्ष्म हो।

स्पष्ट रूप से, अगर हम चर कोड दिखाते हैं, तो चर की वास्तविक चौड़ाई के लिए सभी दांव पलट जाते हैं। Word या LO Writer में दिखाई देने वाली छिपी हुई फॉर्मेटिंग के लिए भी यही स्थिति है।

Paratext के स्पेस के “सरलीकरण” के बारे में, मैं प्रस्ताव दूंगा कि Paratext कई स्पेस को एकल स्पेस में संपीड़ित करना जारी रखे, लेकिन केवल वास्तविक स्पेस U+0020 के लिए। कोई भी अन्य स्पेस या छिपी हुई फॉर्मेटिंग चर बनाए रखे जाएंगे।

अंततः, हमें शायद Paratext में उन छिपी हुई फॉर्मेटिंग चरों को सीधे टाइप करने के लिए कुछ शॉर्टकट्स की आवश्यकता होगी, लेकिन अभी के लिए, हम उन चरों को टाइप करने के लिए AUTOCORRECT.TXT और/या Keyman कीबोर्ड्स पर निर्भर कर सकते हैं।

ठीक है, तो यह एक विचार है, जो मैदान में फेंका गया है… इसके क्या फायदे और नुकसान हैं? आपके पास क्या अन्य विचार हैं?

English से मशीन-अनुवादित मूल दिखाएं

Comments

यह वह बात थी जिसका मैंने LibreOffice (6) के NBSP को मेरी याद के अनुसार दिखाते हुए कहा था: यह भी सभी चर मोड में नहीं है, बस एक सामान्य व्यू है। मुझे विश्वास है कि यह डिफ़ॉल्ट है। क्या LO 7 में यह वही नहीं है?

आप सही कह रहे हैं कि यह NNBSP नहीं दिखाता है (सभी दिखाओ मोड में भी, लेकिन हमें NBSP और स्पेस के लिए सुविधाजनक गिनती योग्य बिंदु मिलते हैं।

jeffh का डायगोनल प्रस्ताव शानदार है, लेकिन हमें उन अक्षरों वाला फॉन्ट चाहिए होगा। मौजूदा फॉन्ट्स हैं जो फॉन्ट्स के यूनिकोड मानों को दिखाने के लिए अल्फान्यूमेरिक वर्ग का उपयोग करते हैं।

मुझे डर है कि डुप्लिकेट नॉन-नॉर्मल स्पेस की अनुमति देने से मल्टी-स्पेस इंडेंटेशन होगा, बिल्कुल वैसे ही जैसे लोग पहले से ही Word में इस संभावना का दुरुपयोग करते हैं, लेकिन यह अन्य वेब मानकों के टेक्स्ट प्रवाह के साथ मेल खाएगा।

मेरे कीबोर्ड पर NBSP वर्षों से है, लेकिन मेरे पास डैगर, कॉपीराइट, और खाली सर्कल जैसी चीज़ें भी हैं।

English से मशीन-अनुवादित मूल दिखाएं

---

मेरे LO Writer 7 कॉन्फ़िगरेशन में Tools - Options - LibreOffice Writer - Formatting Aids में एक विकल्प बंद था, Non-breaking spaces विकल्प बंद था। इसे चालू करने पर मुझे वह ग्रे वर्ग मिलता है जिसके बारे में आप बात कर रहे थे:

लेकिन बिंदु नहीं…

English से मशीन-अनुवादित मूल दिखाएं

Answer 5

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

(एक पार्श्व टिप्पणी के रूप में - क्योंकि मुझे लगता है कि मैंने कुछ चरों को कीबोर्ड करने के तरीकों के बारे में कुछ उल्लेख देखे हैं जो मानक कीबोर्ड पर नहीं दिखते … उन लोगों के लिए जो पहले से नहीं जानते, तीसरे पक्ष के ऐप्लिकेशन के बिना असामान्य चरों को कीबोर्ड करना Windows में Character Map ऐप्लिकेशन का उपयोग करके आसान बनाया जा सकता है। जब आप चर मैप में किसी चर पर क्लिक करते हैं, तो कई चरों के लिए ऐप्लिकेशन के निचले दाएं कोने में एक “Keystroke” शॉर्टकट दिखाया जाता है। वह शॉर्टकट Alt दबाए रखकर और numpad (अक्षरों के ऊपर वाले अंकों के बजाय) से चार अंक टाइप करके कीबोर्ड किया जा सकता है। उदाहरण के लिए: Alt+0160 एक नो-ब्रेक स्पेस (U+00A0) टाइप करता है, Alt+0169 © प्रतीक उत्पन्न करता है, एन-डैश Alt+0150 – है, जबकि एम-डैश Alt+0151 — है।)

English से मशीन-अनुवादित मूल दिखाएं

Answer 6

DBL के माध्यम से डिजिटल प्रकाशन के संबंध में केवल एक टिप्पणी। Paratext अपलोडर USX बंडल बनाने के समय नो-ब्रेक स्पेस को हटा देता है जिसे हम प्रकाशक के साथ साझा करते हैं। दुर्भाग्य से, जब कोई टेक्स्ट डिजिटल रूप से साझा किया जा रहा होता है, तो नो-ब्रेक स्पेस ने ऐतिहासिक रूप से समस्याएं पैदा की हैं।

English से मशीन-अनुवादित मूल दिखाएं

Comments

anon175865:

दुर्भाग्य से, जब कोई टेक्स्ट डिजिटल रूप से साझा किया जा रहा होता है, तो नो-ब्रेक स्पेस ने ऐतिहासिक रूप से समस्याएं पैदा की हैं।

और नो-ब्रेक स्पेस का उपयोग न करने के बारे में क्या? यहाँ Parole de Vie की एक यादृच्छिक पृष्ठ है, एक सम्मानित फ्रेंच अनुवाद, जिसे YouVersion में देखा गया है, एक सम्मानित बाइबल ऐप:

image360×760 123 KB

उच्च प्रकाशित टूटे हुए (समस्या वाले) पंक्चुएशन ब्रेक्स का ध्यान दें। हर बार जब मैं इसे देखता हूं, मैं कांप उठता हूं, और मैं इसे DBL से निकाले गए टेक्स्ट पर बहुत अक्सर देखता हूं, बिल्कुल (मेरा अनुमान है) क्योंकि मान्य नो-ब्रेक स्पेस को सामान्य स्पेस में बदल दिया गया है।

अगर हम Paratext में नो-ब्रेक स्पेस को अच्छी तरह से संभालते हैं, तो मैं मानता हूं कि अपलोडर को DBL में अपलोड करते समय उन्हें हटाना नहीं चाहिए। तो आइए इसे करें!

English से मशीन-अनुवादित मूल दिखाएं

---

मैं सहमत हूं कि वे “ऐतिहासिक रूप से” समस्याएं पैदा करते हैं। यूनिकोड से पहले यह हर जगह सच होता, लेकिन अगर कंटेंट-प्रोड्यूसर और डाउनस्ट्रीम प्रकाशक अभी भी विशेष स्पेस का समर्थन करना सीखने में असफल रहे हैं, तो यह समय हो गया है कि वे ऐसा करें।

आजकल NBSP को हटाना एक गलती है, क्योंकि हम जो डिस्प्ले तकनीकें उपयोग करते हैं, उन सभी में सही ढंग से एन्कोडेड स्पेस को संभालने की प्रक्रिया होती है (HTML, XML, TeX, inDesign), और ये स्पेस दुनिया के कई बहुसंख्यक और अल्पसंख्यक भाषाओं के स्टाइल गाइड का हिस्सा हैं। Paratext के तहत कोई भी कोड बदला जा सकता है, जिसमें आंतरिक डिस्प्ले और USX निर्यात शामिल हैं। TeX और SAB पहले से ही सभी इन स्पेस को संभालते हैं, वरना प्रिंट ड्राफ्ट या ptxPrint में प्रिंट-ड्राफ्ट-चेंजेस हैक काम नहीं करता होगा (शायद PTXPrint से कोई व्यक्ति अपना मत दे सके)। अगर USFM और USX मानक वर्तमान में नो-ब्रेक स्पेस की अनुमति नहीं देते हैं, तो उन्हें संशोधित करने की आवश्यकता होगी।

मुझे पता था कि यह परिवर्तन पूरी पाइपलाइन में किया जाना होगा, लेकिन इससे इसका महत्व कम नहीं होता। Paratext, Chorus, USFM, USX, और अन्य को उन्हें हटाना बंद करना होगा और उनका समर्थन करना और उन्हें प्रदर्शित करना शुरू करना होगा। मुझे संदेह है कि मुख्य एज केस तब होंगे जब कोई व्यक्ति हर स्पेस को NBSP से बदलने का चुनाव करे और एक पंक्ति से बाहर हो जाए।

यहाँ कैमरून में, मैं अभी भी भाषा के IPA चरों को “विशेष चर” कहता हूं, लेकिन हमारे पास जो व्यापक समर्थन है, उससे यहाँ के एक भाषाविद ने हाल ही में मुझे याद दिलाया कि हमें उन्हें बस “चर” कहना चाहिए। टेक्स्ट में चरों की एक विस्तृत विविधता का समर्थन नहीं कर सकने वाले टूल्स अब कम और कम हो रहे हैं। अंतिम सीमा कमांड-लाइन Windows सॉफ्टवेयर के फोल्डर नामों में विशेष चरों का समर्थन करने की प्रतीत होती है। Windows ने वर्षों से इसका समर्थन किया है, लेकिन चीज़ें अभी भी बिगड़ जाती हैं।

~Matthew_Lee

English से मशीन-अनुवादित मूल दिखाएं

---

नमस्ते jeffh,

मैंने आपकी चिंता को YouVersion के हमारे मित्रों को भेज दिया है…हालांकि मेरा मानना है कि नो-ब्रेक स्पेस को सामान्य स्पेस में बदलने की प्रक्रिया Paratext अपलोडर में की जाती है, YouVersion (या किसी अन्य प्रकाशक के) के पक्ष पर नहीं।

English से मशीन-अनुवादित मूल दिखाएं

---

YouVersion के लोगों से जुड़ने के लिए धन्यवाद @anon175865। हाँ, जैसा कि आपने उल्लेख किया, मेरा अनुमान है कि कोई भी नो-ब्रेक स्पेस पहले से ही DBL में गायब हो चुके हैं, Paratext अपलोडर द्वारा हटा दिए गए हैं। तो यह उनकी गलती नहीं है। हालाँकि, @Matthew_Lee और मैं जो कह रहे हैं वह यह है कि हमें अपनी पाइपलाइन को ठीक करने की आवश्यकता है, ताकि Paratext इन विशेष स्पेस के साथ आरामदायक हो और उन्हें आसानी से संभाल सके, और अपलोडर उन्हें हटा न दे। तब वे DBL में होंगे, और जब YouVersion उन टेक्स्ट का उपयोग करेगा, तो वे स्क्रीन पर सही ढंग से दिखाई देंगे।

English से मशीन-अनुवादित मूल दिखाएं

Answer 7

WSTech ने इस थ्रेड में कुछ मुद्दों पर चर्चा की, और मैं एक सारांश भेजना चाहता था:

• मेरा संदेह है कि दिखाया जा रहा बहुत बड़ा टिल्ड (NBSP के लिए) Charis SIL फॉन्ट से है। अगर एक अलग लैटिन स्क्रिप्ट फॉन्ट का उपयोग किया जाता है, तो क्या टिल्ड का आकार बदलता है?
• ऐसे फॉन्ट हैं जो पंक्चुएशन चिह्नों के आसपास स्पेसिंग को स्वतः समायोजित करते हैं (जो फ्रेंकोफोन क्षेत्रों में आवश्यक है) लेकिन वे दुर्लग प्रतीत होते हैं। इसलिए आवश्यक स्पेस डालना सबसे अच्छा दृष्टिकोण प्रतीत होता है।
• स्पेस के यूनिकोड मानों को दिखाने के लिए एक अलग फॉन्ट का उपयोग करना (यानी, टेक्स्ट के लिए उपयोग किए जाने वाले मुख्य फॉन्ट नहीं) काम कर सकता है।
• PTXprint सभी विभिन्न स्पेस चरों को संभाल सकता है।

English से मशीन-अनुवादित मूल दिखाएं

Comments

WSTech ने हाल ही में हमारे फॉन्ट्स में स्पेस की चौड़ाई को समायोजित किया है। पीछे की संगतता के लिए, लैटिन स्क्रिप्ट फॉन्ट्स (और शायद कुछ अन्य) हमारे नए सिफारिशों का पालन सभी स्पेस के लिए नहीं करते हैं, केवल कुछ स्पेस के लिए।

English से मशीन-अनुवादित मूल दिखाएं

---

इतने सारे लोगों, जिनमें WSTech और Paratext शामिल हैं, से सुनकर मुझे प्रोत्साहन मिला है। हम इसमें आगे कैसे बढ़ें, क्या इसे एक फीचर रिक्वेस्ट (feature request) के रूप में लिखना होगा और सामान्य प्राथमिकता प्रक्रिया (prioritization process) से होकर गुजारना होगा?

बड़ी समस्याएँ (जिन्हें अलग-अलग संभाला जा सकता है) ये हैं:

1. इस थ्रेड में उल्लिखित NBSP और समान चरों को PTX/USFM/USX/DBL पाइपलाइन में कहीं भी मौजूद रहने दें (और जैसा ज़रूरी हो, उससे जुड़े प्रदर्शन संबंधी मुद्दों का समाधान करें)। यह पहला और सबसे महत्वपूर्ण बाधा है। इसके बाद हम आगे बढ़ते हुए व्यक्तिगत प्रोजेक्ट्स में स्पेसिंग को “सुधार” सकते हैं।

• इन चरों को PTX स्टैंडर्ड और प्रीव्यू में सही ढंग से प्रदर्शित होना चाहिए।
• पंक्तिचिह्न और चर जाँच (Punctuation and Character checks) में इन्हें अलग-अलग पहचाना जाना चाहिए।
• उद्धरण और संख्या सेटिंग्स (Quotation and Number settings) में इन्हें स्वीकार किया जाना चाहिए (ध्यान दें कि FLEx, Configure Dictionary में स्पेस दिखाने के लिए बिंदुओं का उपयोग करता है)।

2. इन चरों को देखने के लिए Paratext के अंदर एक तरीका प्रदान करें।

• विशेष अस्थायी फॉन्ट्स एक सुझाई गई संभावना रही है।
• हमेशा चालू रहने वाले ग्रे वर्ग (grey squares) का सुझाव दिया गया है।
• Word/LibreOffice के समान सभी चर दिखाने की सुविधा।
  • मेरे एक उपयोगकर्ता ने सुझाव दिया कि Show/hide सुविधा एक संवाद (dialogue) खोल दे (जैसे Basic Checks डायलॉग), जिससे आप यह निर्दिष्ट कर सकें कि कौन से विशेष चर दिखाए जाने हैं (सामान्य स्पेस, NB स्पेस, जॉइनर्स, नॉन-ब्रेकिंग हाइफ़न, द्विदिशात्मक मार्कर, सॉफ्ट और हार्ड रिटर्न्स)। मैं ऐसे मामलों की कल्पना कर सकता हूँ जहाँ तकनीशियन सभी मार्कर हाइलाइट किए हुए चाहते हैं (जो मैं बाहरी टूल्स में अक्सर करता हूँ), और ऐसे स्थितियाँ जहाँ टीम को केवल “विशेष” मार्कर हाइलाइट किए हुए चाहिए।
  • 

~Matthew_Lee

English से मशीन-अनुवादित मूल दिखाएं

---

Matthew_Lee:

हम इसमें आगे कैसे बढ़ें, क्या इसे एक फीचर रिक्वेस्ट के रूप में लिखना होगा और सामान्य प्राथमिकता प्रक्रिया से होकर गुजारना होगा?

हाँ, वह सबसे अच्छा विकल्प होगा। किसी भी फीचर रिक्वेस्ट में इस थ्रेड का लिंक जोड़ना भी मददगार होगा।

जिन लोगों को फीचर रिक्वेस्ट बनाने की प्रक्रिया के बारे में जानकारी नहीं है - यह सभी Paratext उपयोगकर्ताओं के लिए उपलब्ध है। Paratext के मुख्य मेनू से, Help > Give feedback का चयन करें और जो फॉर्म दिखाई देता है, उसमें Make a suggestion... विकल्प का चयन करें।

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

English से मशीन-अनुवादित मूल दिखाएं

Answer 8

यह अब एक फीचर रिक्वेस्ट के रूप में जमा कर दिया गया है। इस रिपोर्ट में इस थ्रेड का उल्लेख किया गया था।

संबंधित रिपोर्टें:
https://paratext.myjetbrains.com/youtrack/issue/PTX-22626
https://paratext.myjetbrains.com/youtrack/issue/PTUX-1318
https://paratext.myjetbrains.com/youtrack/issue/PTX-22623

English से मशीन-अनुवादित मूल दिखाएं

Comments

मैंने YouTrack के अंदर एक और टिप्पणी जोड़ी:

अदृश्य चरों को चर और पंक्तिचिह्न सूचियों (Character and Punctuation inventories) में सूचीबद्ध किया जाना चाहिए, जो यह दर्शाने का हमारा सर्वोत्तम संकेत होगा कि वे मौजूद हैं और किस संदर्भ में मौजूद हैं। उद्धरण सेटिंग्स ([NBSP]”) में, पवित्र ग्रंथ संदर्भ सेटिंग्स (1[NBSP]Kings) में, और संख्या सेटिंग्स (10[NBSP]000) में इन्हें मान्य विभाजक (valid separators) के रूप में स्वीकार किया जाना भी चाहिए। इससे कई उपयोग के मामलों को कवर किया जा सकेगा।

English से मशीन-अनुवादित मूल दिखाएं

Answer 9

मैं यहाँ देर से आया हूँ, विषय अभी-अभी पता चला।

मैं उन प्रस्तावित सुविधाओं के लिए अपना +1, या बल्कि +100000 देता हूँ। मैं एक अन्य भाषा के लिए काम करता हूँ, जहाँ ऐतिहासिक और सह-अस्तित्व के कारण वर्तनी (orthography) को फ्रेंच के जितना हो सके करीब होने की कोशिश होती है।

मैं सभी को याद दिलाता हूँ कि किसी भी तकनीकी परिवर्तन करने से पहले फ्रेंच के बारे में पढ़ें। फ्रेंच टाइपोग्राफी आम लोगों के सोचने से भी अधिक जटिल है। हाँ, कुछ पंक्तिचिह्न चरों के चारों ओर स्पेस होते हैं, लेकिन वे एक जैसे नहीं होते हैं। उदाहरण के लिए, कॉलन के सामने (बाएँ) स्पेस पूर्ण-आकार (full-size) का होना चाहिए।

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

grafik1237×800 71 KB

उपयोगी कागज़ी किताबें भी उपलब्ध हैं, जैसे “Lexique des règles typographiques” en usage à l’imprimerie nationale" by imprimerie nationale (de la France) और “Règles de l’écriture typographique du français à l’usage des personnes qui exercent une activité sur MAC ou PC” by Yves Perrousseaux।

English से मशीन-अनुवादित मूल दिखाएं

Answer 10

अब तक हम PT में टिल्ड (tilde) का पूर्ण उपयोग और स्वीकार कर रहे हैं, जैसे अन्य लोग XeTeX से निपटते हैं और मेरा उनका आदर है — लेकिन उन जैसा बनने की मेरी इच्छा नहीं है।

ऐप और पवित्र ग्रंथ-अंश (scripture-portion) द्वारा बार-बार प्रकाशन की तर्कशक्ति भी हमारे संदर्भ के लिए प्रासंगिक है। और टिल्ड जल्द ही जाना चाहिए।

अधिक फॉन्ट्स को narrow-non-breaking प्रदान करने की भी आवश्यकता है। लगता है कि सभी SIL फॉन्ट्स भी ऐसा नहीं करते हैं। यदि वे करते हैं, तो मुझ पर चिल्ला दीजिए; यह मेरे लिए अच्छी खबर होगी, जो चिल्लाने लायक है।

अभी टिल्ड दर्ज करने के लिए (NNBSP उम्मीद है जल्द ही), मैंने PT के लिए एक चतुराई भरी सुविधा का आविष्कार किया है, जहाँ मैं inbuilt autocorrect.txt सुविधा का उपयोग करता हूँ। उदाहरण के लिए, टिल्ड और एक विस्मय चिह्न प्राप्त करने के लिए, मैं तीन बार विस्मय चिह्न दबाता हूँ और PT बाकी सही तरीके से करता है। मेरे पास उन सभी पंक्तिचिह्नों के लिए यह सेट-अप है जिनकी विशेष देखभाल की आवश्यकता होती है।

(और मैं इसका उपयोग Abraham, Jesus या Jerusalem जैसे बार-बार आने वाले शब्दों को दर्ज करने के लिए भी करता हूँ।)

English से मशीन-अनुवादित मूल दिखाएं