एक चालाक तरीका जिससे encoding converter को कुछ टेक्स्ट को छोड़ने के लिए मजबूर किया जा सके

Question

मैं इस समस्या के लिए बहुत परेशान हो रहा था, और अभी-अभी एक समाधान खोजा है, इसलिए मैं इसे यहाँ साझा कर रहा हूँ, ताकि कोई अन्य व्यक्ति भी यह न खोजे कि कुछ टेक्स्ट को स्वतः-अनुवादित (auto-transliterated) होने से कैसे रोका जाए। यह समाधान दोनों ही तरह से विरोधाभासी (counter-intuitive) और चालाक (shady) है।

संक्षेप में:

अगर आपके पास कोई गैर-देशी (non-vernacular) टेक्स्ट है जिसे encoding converter द्वारा स्वतः-अनुवादित (auto-transliterated) नहीं किया जाना चाहिए, बल्कि इसे उसके मूल encoding में प्रकाशित किया जाना चाहिए, तो उसे एक कस्टम कैरेक्टर स्टाइल में लपेटें, और उस कस्टम स्टाइल को nonpublishable गुण (property) दें।

हाँ, nonpublishable गुण, nonvernacular की बजाय, जो उचित लगता। nonvernacular गुण वास्तव में इस बात को प्रभावित नहीं करता कि क्या अनुवादित (transliterated) किया जाएगा, और nonpublishable गुण वर्तमान में इस बात को प्रभावित नहीं करता कि क्या प्रकाशित किया जाएगा, कम से कम Publishing Assistant द्वारा नहीं।

विस्तृत पृष्ठभूमि:

मैं एक स्वतः-अनुवादित (auto-transliterated) प्रोजेक्ट को टाइपसेट करने वाला हूँ। प्रोजेक्ट में राष्ट्रीय भाषा के कुछ शब्द शामिल हैं। इन्हें ग्लॉसरी प्रविष्टियों, प्रस्तावना सामग्री और फुटनोट्स में पाया जा सकता है, और इन्हें \znp …\znp* मार्करों के अंदर टैग किया गया है, जिन्हें मैंने custom.sty में nonvernacular, publishable कैरेक्टर स्टाइल के रूप में परिभाषित किया था, क्योंकि वही तो वह था।

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

लेकिन ऐसे टेक्स्ट को nonvernacular के रूप में चिह्नित करने से इसे अनुवादित (transliterated) होने से रोकने में कोई असर नहीं पड़ा।

TECkit map को यह भी नहीं बताया जा सकता कि \znp …\znp* मार्करों में बंद टेक्स्ट को नजरअंदाज कर दिया जाए, क्योंकि मार्कर स्वयं प्रोसेसिंग के लिए map में पास नहीं किए जाते। (संभवतः पहले ऐसा होता था, क्योंकि Paratext Help दस्तावेज़ीकरण अभी भी कहता है, “सुनिश्चित करें कि आप जिस TECkit.map फ़ाइल का उपयोग कर रहे हैं वह USFM मार्करों को सुरक्षित रखती है ताकि वे परिवर्तित न हों।”)

मुश्किल समाधान publishable गुण को nonpublishable में बदलना था। इससे Publishing Assistant को इसे प्रकाशित करने से नहीं रोका गया।

मुझे नहीं पता कि क्या यह अन्य आउटपुट पथों (SAB / Print Draft / PtxPrint / YouVersion via DBL) के साथ चीज़ों को बिगाड़ देगा, चाहे वर्तमान में या भविष्य में वे चुपचाप nonpublishable टेक्स्ट को छोड़ दें, इसलिए यह इस कार्य-सूत्र (workaround) के साथ एक निश्चित चिंता है।

nonpublishable के टेक्स्ट को स्वतः-अनुवाद (auto-transliteration) से छूट देने के अलावा, मुझे स्पष्ट नहीं है कि इनमें से किसी भी गुण का अन्य क्या प्रभाव हो सकता है। क्या कहीं ऐसा दस्तावेज़ीकरण है जो इसकी व्याख्या करता है?

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

Answer 1

PTXprint (या बल्कि, ptx2pdf TeX मैक्रो जो यह उपयोग करता है) nonpublishable के रूप में चिह्नित किए गए किसी भी चीज़ को लगभग-टिप्पणी (almost-comment) के रूप में मानेगा। python प्रोग्राम भी अपने स्वयं के संशोधन लागू कर सकता है; मुझे नहीं पता।

Nonpublishable पैराग्राफ और कैरेक्टर स्टाइल आउटपुट नहीं उत्पन्न करेंगे, वास्तव में यह verse numbers आदि को दबाने का एक तरीका है।
मैंने लगभग टिप्पणी कहा, क्योंकि यह किसी भी चीज़ को सच्ची टिप्पणी के रूप में नहीं मानता: सब कुछ अभी भी पढ़ा और व्याख्यायित किया जाता है, बस पैराग्राफ/कैरेक्टर स्टाइल के अंत में सामग्री को हटा दिया जाता है।
इसलिए आप वहाँ \invalid USFM नहीं डाल सकते, और ranged milestones जो nonpublishable टेक्स्ट में शुरू होते हैं और समाप्त नहीं होते, वे बाद में भी प्रभावी रहेंगे।

हालाँकि, PTXprint के साथ stylesheet-लोडिंग की अनुक्रमणिका को देखते हुए, आप custom.sty में कुछ nonpublishable सेट कर सकते हैं और फिर बाद की stylesheet में उस सेटिंग को ओवरराइड कर सकते हैं।

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

Comments

अरे, यह जानकर अच्छा लगा। धन्यवाद!

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

Answer 2

यह वास्तव में विरोधाभासी (counter-intuitive) है और यह अतीत में इस तरह काम नहीं करता था। इसलिए मुझे विश्वास है कि यह एक बग (bug) होना चाहिए। अतीत के प्रोजेक्ट्स में मैंने \tl…\tl* (Transliterated Word) का उपयोग परिवर्तन को ब्लॉक करने के लिए काफी सफलतापूर्वक किया है, जिसमें publishable nonvernacular की विशेषताएँ होती हैं। मैंने front और back matter के लिए frtback.sty stylesheet के माध्यम से कस्टम पैराग्राफ स्टाइल्स के लिए भी इन विशेषताओं का उपयोग किया। और nonpublishable को Publishing Assistant से InDesign तक आना नहीं चाहिए।

आशा है कि हम इस व्यवहार को सही करवा सकते हैं, इसलिए तब तक आपको अपने markup के साथ लचीला रहना चाहिए…

आशीर्वाद,

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

Comments

धन्यवाद, Shegnada। मूल markup वास्तव में \tl ...\tl* था, जो यह दर्शाता है कि अतीत के किसी बिंदु पर, इस प्रोजेक्ट में स्वतः-अनुवाद (auto-transliteration) को रोकने के लिए वह काम करता था। (NT कई वर्षों पहले प्रकाशित किया गया था, और अब हम पूरा बाइबल कर रहे हैं।) उस स्थिति में, यह बग एक regression है, कुछ ऐसा जो दूसरे कुछ को संबोधित करते समय टूट गया। मैंने इसे PTXS-31555 के रूप में रिपोर्ट किया है। एक बार जब यह ठीक हो जाएगा, तो यह बस \znp की परिभाषा को अपडेट करने की बात होगी जो मेरे पास custom.sty और frtbak.sty में है, ताकि nonpublishable को publishable से बदला जा सके।

लेकिन अब मुझे संदेह है कि क्या यह कार्यक्षमता जानबूझकर बदली गई थी, किसी के तर्क के आधार पर कि \tl टेक्स्ट को कोनवर्टर के माध्यम से भेजा जाना चाहिए। इस प्रोजेक्ट ने तब से OT में \tl मार्कर का उपयोग स्रोत भाषाओं से अनुवादित (transliterated) शब्दों को चिह्नित करने के लिए किया है, जैसे purim और mene, tekel, parsin। अनुवाद टीम की 의도 है कि इन शब्दों को कोनवर्टर द्वारा प्रोसेस किया जाएगा ताकि वे प्रोजेक्ट की उसी लिपि में हों, लेकिन जो भी लिपि हो, उसे इटैलिक किया जाएगा। इसलिए मुझे लगता है कि जब यह बग ठीक होगा, तो हमें \tl को इस प्रोजेक्ट में vernacular के रूप में पुनर्परिभाषित करने की याद भी रखनी होगी, यह सुनिश्चित करने के लिए कि यह कोनवर्टर द्वारा प्रोसेस किया जाए। क्या यह ऐसा करने का तरीका लगता है?

मैं अभी भी publishable/nonpublishable और vernacular/nonvernacular गुणों के संतुलित प्रभावों के बारे में दस्तावेज़ीकरण खोजना चाहूँगा। अब तक मुझे केवल यह पता है कि nonpublishable का परिणाम टेक्स्ट को encoding परिवर्तन से बचने और प्रकाशनों में दिखाई देने से बचने का होना चाहिए। मेरा मानना है कि nonvernacular encoding परिवर्तन से बचने के लिए तैयार है (हालाँकि वह टूटा हुआ है), और मुझे किसी अन्य संतुलित प्रभाव के बारे में पता नहीं है। मुझे संदेह है कि क्या उनमें से किसी का spelling wordlist, character inventory, आदि पर कोई प्रभाव है?

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

---

मेरा मानना है कि जब तक आप एक कस्टम stylesheet का उपयोग करते हैं, जैसे आपके मामले में custom.sty, और hashtags के साथ दस्तावेज़ीकरण करते हैं कि आप क्या कर रहे हैं और क्यों, और पहले \tl स्थान पर एक Paratext नोट जोड़ते हैं जिस व्यवहार की आप खोज कर रहे हैं, आपको अपने PubAssist/InDesign पथ पर ठीक होना चाहिए।

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

आपको यह ध्यान में रखना चाहिए कि आपके पास दो, या शायद जैसा मैं आमतौर पर रखता हूँ, तीन प्रोजेक्ट शामिल हैं। मूल प्रोजेक्ट, स्वतः परिवर्तित प्रोजेक्ट (असंपादनीय), और (मैं सुझाव देता हूँ) प्रकाशन के लिए उपयोग किया जाने वाला तीसरा प्रोजेक्ट जिसका टेक्स्ट परिवर्तित प्रोजेक्ट से आयात करके प्राप्त होता है। इन प्रोजेक्ट्स में से प्रत्येक के पास अलग-अलग कस्टम stylesheets हो सकते हैं और जबकि यह महत्वपूर्ण है कि पहले प्रोजेक्ट में वे स्टाइल विशेषताएँ हों जो कोनवर्टर को सही ढंग से काम करने दें, प्रकाशन के लिए जिस प्रोजेक्ट से आप प्रकाशित कर रहे हैं, उसके stylesheets इनसे अलग हो सकते हैं और वे केवल प्रकाशित आउटपुट को प्रभावित करते हैं। इस प्रकार आपके पास कुछ लचीलापन है, विशेष रूप से अगर आप उस तीसरे प्रोजेक्ट का उपयोग करते हैं। अगर आप चाहें तो मैं तीसरे प्रोजेक्ट के अन्य लाभों के बारे में आपसे अधिक चर्चा कर सकता हूँ, लेकिन मैं दूसरे और तीसरे प्रोजेक्ट्स को केवल आउटपुट मानूँगा और दस्तावेज़ीकरण, आदि, हमेशा मूल प्रोजेक्ट में पाए जाने चाहिए।

आशीर्वाद,

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