क्या \qt-s\* \wj को बदल देगा? क्या मार्कर जाँच (markers check) खराब है? इतने सारे सवाल

Question

जिस कठिन और अफरा-तफरी भरी प्रक्रिया में मैंने इस्तीमाल किया है जिसमें यीशु के वचनों को \wj … \wj* के साथ टैग किया जाता है, ताकि एक Paratext कस्टम टूल बनाया जा सके जो Paratext प्रोजेक्ट पर उन्हें लागू करे (संबंधित Glyssen प्रोजेक्ट में चरित्र आवंटन के अनुसार), उसमें डूबने के बाद, मैंने एक ऐसे टैगिंग सिस्टम की तलाश की जो अनुवादक के लिए अधिक सहज हो।

मेरी \wj … \wj* टैगिंग सिस्टम से शिकायत यह है: यह रेंडरिंग सॉफ्टवेयर की सुविधा के लिए डिज़ाइन किया गया है, अनुवादक की सुविधा के लिए नहीं। इन टैग्स को सफलतापूर्वक लागू करने के लिए, आपको हर श्लोक नंबर पर टैग बंद और फिर से खोलना होगा। और हर पैराग्राफ ब्रेक पर। और फिर, आपको इसके भीतर हर शब्द/अक्षर मार्कर में एक प्लस (+) प्रतीक जोड़ना होगा, जैसे +w …+w* और +nd …+nd*।

मेरे लिए सबसे चौंकाने वाली बात यह है कि यदि आप मार्कर जाँच (markers check) पास करना चाहते हैं, तो आपको हर फुटनोट पर भी टैग बंद और फिर से खोलने की आवश्यकता होती है!! क्या यह वास्तव में आवश्यक है, या मार्कर जाँच बिना किसी कारण के इन सभी चेतावनियों को जनरेट कर रही है?

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

इसलिए मुझे USFM3 में milestones सुविधा से परिचित कराया जाना बहुत खुशी का विषय था, जो ठीक इसी उद्देश्य के लिए डिज़ाइन की गई है। लेकिन अब मेरे पास और भी सवाल हैं…

पहला, क्या यह \wj मार्किंग को बदल देगा? यदि कोई प्रोजेक्ट जो \qt-s …\qt-e मार्कर का उपयोग करता है, लाल-अक्षर प्रकाशन चाहता है, तो क्या उसे अतिरिक्त रूप से \wj मार्किंग जोड़नी होगी? ऐसा बहुत ही अनावश्यक और अफरा-तफरी भरा लगता है।

दूसरा, क्या हम यह मान सकते हैं कि पैराटेक्स्टुअल फील्ड, जैसे \s, \r, और \f, \x की तरह, सक्रिय \qt-s के लिए आंतरिक अपवाद हैं? अर्थात्, आप पहाड़ों पर उपदेश के शुरुआत में \qt-s |who=Jesus* रख सकते हैं, और इसके अंत में \qt-e* रख सकते हैं, और आपका काम हो जाएगा। पैराग्राफ और फुटनोट्स के आधार पर 120 या उससे अधिक टैग जोड़ों के बजाय एक जोड़ा, और ग्लॉसरी-टैग किए शब्दों के नेस्टिंग के साथ फुसलाने की कोई ज़रूरत नहीं। ऐसा लगता है कि जो चीज़ें कंप्यूटर स्वतः तय कर सकता है (लाल अक्षरों का अनुमान लगाने के लिए), उन्हें टेक्स्ट में अनावश्यक रूप से मार्करों से भरा नहीं जाना चाहिए।

तीसरा, “who” एट्रिब्यूट के लिए सर्वोत्तम प्रथाएँ क्या हैं? क्या टूल्स इनकी उम्मीद अंग्रेज़ी नाम/विवरणों की करेंगे, जैसे “Jesus” और “spies from Pharisees and Herodians”? क्या ये Glyssen द्वारा उपयोग किए जाने वाले वही चरित्र नाम होने चाहिए?

चौथा, ऐसे संदर्भों में इन्हें किस हद तक मार्क किया जाना चाहिए जहाँ विभेदन (disambiguation) की आवश्यकता नहीं है? कुछ श्लोकों में, यीशु एकमात्र चरित्र है जो बोल सकता है, जबकि दूसरों में, एक से अधिक व्यक्ति बोलते हैं, और विभेदन वास्तव में आवश्यक है। क्या ऐसे मामलों में बोलने वाले टैगिंग से टेक्स्ट को अनावश्यक रूप से भरा नहीं जाना चाहिए?

ठीक है, यही मेरे सवाल हैं अभी के लिए।

मुझे अपने WordsOfJesus टैगिंग-टूल को उन प्रोजेक्ट्स पर भी टेस्ट करने में रुचि होगी जहाँ Glyssen प्रोजेक्ट में चरित्र आवंटन किया गया है। यदि आपके पास ऐसा कोई प्रोजेक्ट है, तो कृपया मुझे बताएं कि क्या आप मुझे इसकी एक कॉपी साझा करने के लिए तैयार हैं। -धन्यवाद!

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

Answer 1

यह वास्तव में उपयोगी प्रतिक्रिया है, धन्यवाद।

मुझे खेद है कि मेरा उत्तर आपके सवालों के समाधान प्रदान नहीं करता है, बल्कि यह आपके मुद्दों और चिंताओं से संबंधित आपके लिए सवाल हैं।

मेरा मानना है कि आप एक प्रोजेक्ट एडमिन हैं और ऐसा लगता है कि आप मार्कअप का उपयोग करने और संबंधित नियमों को सीखने में आरामदायक हैं। मैं आप और आपके टीम (यदि आपके पास कोई है) के बारे में कुछ सवाल पूछना चाहता हूँ और आप Paratext का उपयोग कैसे करते हैं:

1. क्या आपके प्रोजेक्ट में अन्य टीम सदस्य हैं जो USFM मार्कअप को एक बाधा मानते हैं जिसे वे पार नहीं कर सकते (या सीखना पसंद नहीं करते)?
2. क्या आप अधिक जटिल नेस्टेड मार्कअप पर काम करते समय मुख्य रूप से unformatted view या standard view का उपयोग करते हैं?
3. क्या आपको यह उपयोगी लगेगा कि आपको मार्कअप को संपादित करने की आवश्यकता न हो और बजाय इसके कि टेक्स्ट का एक हिस्सा हाइलाइट करके उसे एक निश्चित एट्रिब्यूट या एट्रिब्यूट्स का सेट दिया जाए?
4. यदि हम ऊपर बताई गई चीज़ जैसा कुछ करते हैं, तो क्या यह उपयोगी होगा यदि Paratext पृष्ठभूमि में आपके एट्रिब्यूट्स के बारे में चयनों को सबसे सरलता से कैसे प्रस्तुत करना है, यह तय कर ले?
5. क्या ऊपर दिया गया आइटम टेक्स्ट पर नियंत्रण की हानि जैसा लगेगा?
6. क्या आप चाहेंगे कि आप उस मार्कअप को संपादित करने में सक्षम हों जो Paratext ने ऊपर दिए गए बिंदु में बनाया था (और यदि संपादन से त्रुटियाँ हुईं तो सामान्य चेतावनियाँ देखें)? या क्या केवल इसे देखना पर्याप्त होगा?

मुझे जानने में रुचि है कि क्या टीमों को उनके टेक्स्ट के पीछे के मार्कअप की परवाह होती है। या क्या वे इस बात की अधिक परवाह करते हैं कि सही एट्रिब्यूट्स शब्दों या टेक्स्ट के हिस्सों से जुड़े रहें और वे मार्कअप (और USFM सीखने की बाधा, जो मुख्य रूप से अंग्रेज़ी में दस्तावेज़ित है) के बारे में चिंता करने से बचना पसंद करते हैं।

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

Comments

नमस्ते, IanH। अन्य प्रोजेक्ट्स में ऐसे लोग हैं जो + नोटेशन नियमों से पूरी तरह भ्रमित हैं, और शायद कभी भी मेरे जैसे किसी व्यक्ति के बिना उन्हें सही ढंग से नहीं समझ पाएंगे जो इस अफरा-तफरी को साफ करे। एक सॉफ्टवेयर डेवलपर के रूप में, मैं + नोटेशन के कारणों को समझता हूँ, लेकिन फिर भी इसे एक अनावश्यक kludge (अस्थायी/असुंदर समाधान) मानता हूँ, जैसे हर फुटनोट पर \wj …\wj* को रोकना और शुरू करने की आवश्यकता। जब \w का उपयोग Strong’s नंबर टैगिंग के लिए किया जाता है, तो यह बहुत ही अफरा-तफरी भरा हो जाता है। और हाँ, अल्पसंख्यक भाषाओं के साथ ऐसा करने वाले वास्तविक लोग हैं। इसलिए, हाइलाइटिंग और एट्रिब्यूट्स लागू करना और Paratext से मार्कअप को पृष्ठभूमि में संभालने के लिए कहना एक सुधार हो सकता है। इसे एक विकल्प के रूप में प्रस्तुत किया जा सकता है, जैसे वर्तमान standard और unformatted views, जो अभी भी वहाँ हो सकते हैं। मैं अक्सर unformatted view पर वापस आ जाता हूँ जब मैं यह तय करने की कोशिश कर रहा होता हूँ कि स्कीमा त्रुटि का कारण क्या है। इसलिए मुझे नहीं लगता कि शुरुआत में हाइलाइटेड रेंज के साथ मार्कअप को देखने और संपादित करने के विकल्प के बिना सब कुछ करना अच्छा होगा, लेकिन यदि इसे अच्छी तरह से किया जाए तो यह एक सुधार होगा। यह Microsoft Word जैसा अधिक होगा और पुराने WordPerfect और उसके कोड्स जैसा कम, और हम जानते हैं कि उन दोनों के बीच मार्क कैसे खेला गया।当然, Microsoft की सफलता के लिए मौजूदा टेक्स्ट के साथ संगतता महत्वपूर्ण थी, लेकिन अच्छा UI डिज़ाइन भी।
– Paratext उपयोगकर्ता और Haiola के डेवलपर

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

---

नमस्ते IanH,

आपके सवालों के उत्तर देने के लिए:

IanH:

1. क्या आपके प्रोजेक्ट में अन्य टीम सदस्य हैं जो USFM मार्कअप को एक बाधा मानते हैं जिसे वे पार नहीं कर सकते (या सीखना पसंद नहीं करते)?

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

IanH:

2. क्या आप अधिक जटिल नेस्टेड मार्कअप पर काम करते समय मुख्य रूप से unformatted view या standard view का उपयोग करते हैं?

व्यक्तिगत रूप से, मैं हमेशा आगे-पीछे उछलता रहता हूँ।

IanH:

3. क्या आपको यह उपयोगी लगेगा कि आपको मार्कअप को संपादित करने की आवश्यकता न हो और बजाय इसके कि टेक्स्ट का एक हिस्सा हाइलाइट करके उसे एक निश्चित एट्रिब्यूट या एट्रिब्यूट्स का सेट दिया जाए?
4. यदि हम ऊपर बताई गई चीज़ जैसा कुछ करते हैं, तो क्या यह उपयोगी होगा यदि Paratext पृष्ठभूमि में आपके एट्रिब्यूट्स के बारे में चयनों को सबसे सरलता से कैसे प्रस्तुत करना है, यह तय कर ले?

मैं कल्पना कर सकता हूँ कि कुछ उपयोगकर्ताओं के लिए, यह बहुत अच्छा होगा।

IanH:

5. क्या ऊपर दिया गया आइटम टेक्स्ट पर नियंत्रण की हानि जैसा लगेगा?
6. क्या आप चाहेंगे कि आप उस मार्कअप को संपादित करने में सक्षम हों जो Paratext ने ऊपर दिए गए बिंदु में बनाया था (और यदि संपादन से त्रुटियाँ हुईं तो सामान्य चेतावनियाँ देखें)?

बिल्कुल, जिन कई टीमों के साथ मैं काम करता हूँ, उनके लिए। यदि आप मार्करों पर हाथ नहीं लगा सकते, तो आप परिवर्तनों को व्यापक रूप से लागू नहीं कर सकते। वे मैन्युअल रूप से परिवर्तन करने के लिए हमेशा क्लिक करते रहेंगे।

टीमों को उनके टेक्स्ट के पीछे के मार्कअप की निश्चित रूप से परवाह होती है। बस कुछ मामलों में, जैसे \wj, फॉर्मेटिंग नियम काफी परेशान करने वाले होते हैं। यह अच्छा होगा यदि Paratext हमारे लिए उनमें से कुछ विवरणों की देखभाल कर ले और अफरा-तफरी को छिपा दे।

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

Answer 2

anon150053:

पहला, क्या यह \wj मार्किंग को बदल देगा? यदि कोई प्रोजेक्ट जो \qt-s …\qt-e मार्कर का उपयोग करता है, लाल-अक्षर प्रकाशन चाहता है, तो क्या उसे अतिरिक्त रूप से \wj मार्किंग जोड़नी होगी? ऐसा बहुत ही अनावश्यक और अफरा-तफरी भरा लगता है।

यह प्रकाशन के लिए उपयोग किए जाने वाले सॉफ्टवेयर पर निर्भर करता है। मुझे नहीं लगता कि Publishing Assistant milestones को उस तरह से संभालता है जैसा आप चाहते हैं (आपको पक्का करने के लिए उस टीम से संपर्क करना होगा)।

USFM 3.0 milestones मुख्य रूप से ऑडियो उत्पादन करने में सहायता करने के लिए बनाए गए थे (जैसे Glyssen के साथ इंटरफेसिंग) ताकि यह निर्धारित करने में मदद मिल सके कि किसी विशेष बिंदु पर कौन बोलना चाहिए, और इसे एक छपी प्रकाशन के फॉर्मेटिंग को संभालने के लिए डिज़ाइन नहीं किया गया है।

anon150053:

क्या यह वास्तव में आवश्यक है, या मार्कर जाँच बिना किसी कारण के इन सभी चेतावनियों को जनरेट कर रही है?

हाँ, यह आवश्यक है। यह USFM फॉर्मेट की एक सीमा है।

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

Comments

anon291708:

हाँ, यह आवश्यक है। यह USFM फॉर्मेट की एक सीमा है।

इसके लिए धन्यवाद। कृपया मुझे समझने में मदद करें: क्या USFM फॉर्मेट में यह सीमा तब होती है जब एक क्रॉस-रेफरेंस यीशु के वचनों के भीतर आता है? वे एक ही ढंग से संरचित होते हैं। और PA और SAB यीशु के वचनों को ठीक से रेंडर करते हैं, चाहे \wj टैग्स के भीतर क्रॉस-रेफरेंस या फुटनोट हो या न हो। लेकिन मार्कर जाँच फुटनोट के लिए एक चेतावनी जनरेट करती है, लेकिन क्रॉस-रेफरेंस के लिए नहीं। अंतर क्या है?

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

Answer 3

शायद मैं उन सभी मध्यवर्ती \wj और \wj* मार्करों को सम्मिलित करने के लिए कुछ नियमित अभिव्यक्ति (regex) के साथ मदद कर सकता हूँ।
यह regex पैराग्राफ मार्करों, श्लोक नंबरों, पादटिप्पणियों और खंड शीर्षकों के पहले और बाद में \wj को बंद करके फिर से खोलता है।
उपयोग करने के लिए:

1. जिस भी पाठ को चिह्नित करना चाहते हैं, उसके आरंभ में \wj और अंत में \wj* रखें।

• यदि यीशु के वचन पैराग्राफों में फैले हुए हैं, तो आपको \wj को बंद करने की आवश्यकता नहीं है,
• हालाँकि, बहु-अध्याय के एकलोगों (monologues) के लिए, आपको अध्याय के अंत में बंद करने वाला \wj* और अगले अध्याय के आरंभ में खोलने वाला \wj रखना होगा।
  आप इतने सारे पाठ के खंडों के लिए यह कर सकते हैं जितने आप चाहें।

2. एक बार जब आपने पाठ को चिह्नित कर लिया हो, तो Regex Pal में निम्नलिखित चलाएँ
   खोजें (Find):
   (?<=\\wj\s)([^\\]|\\(?!wj\*))*?(?=\\wj\*):::((\s*(\\(b|p\w*|mi?|q\w*)\s|(\\(m?r|m?s\w*)\s.*)+|\s+\\v\s\S+\s|\\(x|ef|f|add)\s.*?\\(x|ef|f|add)\*))+)(\s*)
   प्रतिस्थापित करें (Replace):
   \wj*\1\9\\wj (सुनिश्चित करें कि प्रतिस्थापन के अंत में एक स्थानांतरण (space) शामिल है)

3. यदि आपके लाल अक्षरों वाले पाठ में चरित्र चिह्नन (character markup) है, जैसे \w Pharisees|Pharisee\w* या \tl Talitha cum \tl*, तो आपको टैग में एम्बेडेड चरित्र चिह्नन जोड़ना होगा, जिसका अर्थ है \: के बाद + जोड़ना:
   यह regex चलाएँ:
   खोजें (Find):
   (?<=\\wj\s)([^\\]|\\(?!wj\*))*?(?=\\wj\*):::\\(\w+)([^\\].*?)(\s*)\\\1\*\
   प्रतिस्थापित करें (Replace):
   \\+\1\2\\+\1*\3
   इससे यह उत्पन्न होगा: \+w Pharisees|Pharisee\+w* और \+tl Talitha cum\+tl*
   नोट करें कि cum के बाद का स्थानांतरण (space) \tl* के दाईं ओर ले जाया जाता है

यह वह कोड है जिसे userMenu.txt में सम्मिलित किया जाना चाहिए ताकि आप इसे RegexPal User मेनू से चला सकें:
———\wj Cleanup—————————#f#
\wj*...\wj#r#(?<=\\wj\s)([^\\]|\\(?!wj\*))*?(?=\\wj\*):::((\s*(\\(b|p\w*|mi?|q\w*)\s|(\\(m?r|m?s\w*)\s.*)+|\s+\\v\s\S+\s|\\(x|ef|f|add)\s.*?\\(x|ef|f|add)\*))+)(\s*)#\\wj*\1\9\\wj
fix embedded markers#r#(?<=\\wj\s)([^\\]|\\(?!wj\*))*?(?=\\wj\*):::\\(\w+)(?s)(.*?)(\s*)\\\1\*#\\+\1\2\\+\1*\3

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

Comments

Thanks, CrazyRocky! Great to hear from you again! And what cool regexes!

Hey, a couple things that caught my eye:

I see that you exclude the \add text from \wj marking. Is that because it’s not really an explicit word of Jesus? I’ve been treating it like other character-level formatting, like \nd and \w. But I don’t know whether it’s customary to take the red ink away when a translator adds an implicit word to Jesus’ quote.

Also, I’ve never thought of nesting \wj inside \w like this before. Interesting! I’m curious why you prefer it this way. I’ve always encouraged users to nest it the other way around:
\wj Woe to you \+w Pharisees|Pharisee\+w* and teachers of the Law!\wj*
Are there particular advantages to doing it with \wj on the inside?

Actually, I’ve just put together have a much faster and more reliable way to insert all the \wj tags in the project and nest the \w markers and such. It’s a custom tool for Paratext’s Custom Tools menu. Basically, Glyssen already knows which verses Jesus should be speaking in, and there are just a handful of ambiguous cases to manually disambiguate, so there’s no need to manually go through the text inserting any \wj markers. We use Glyssen’s work to apply the \wj tags wherever they are needed.

But where are they really needed? That was my question, and I saw no instructions in the USFM docs telling users what these markers must close and reopen around. Cross-references work fine without such clutter, as do footnotes, but the markers check complains in the case of footnotes. Now as I’m looking into this further, I realize that even though the marker check does not complain about cross-references, the schema check does. I still think it would be best if the marker check treated footnotes and cross-references consistently. Anyway, I guess I’ll have to make closing and reopening \wj around cross-references and footnotes both standard in my tool. Let me know if you’d be interested in testing it out. -Thanks!

---

anon150053:

मुझे यह देखने को मिलता है कि आप \add पाठ को \wj चिह्नन से बाहर रखते हैं। क्या इसका कारण यह है कि यह वास्तव में यीशु का स्पष्ट वचन नहीं है?

यह शायद इस बात पर निर्भर करता है। मेरे पास एक संस्करण है जिसमें \add सामग्री टिप्पणी (commentary) थी, इसलिए मैं इन्हें लाल के रूप में चिह्नित नहीं करना चाहता था। इसलिए बस regex से \add हटा दें और यह लाल अक्षरों में शामिल हो जाएगा।

anon150053:

साथ ही, मैंने कभी भी \wj को इस तरह \w के अंदर निस्ट करने के बारे में नहीं सोचा था। दिलचस्प है! मुझे जिज्ञासा है कि आप इसे इस तरह क्यों पसंद करते हैं। मैंने हमेशा उपयोगकर्ताओं को इसे उल्टे क्रम में निस्ट करने की सलाह दी है

मैंने अपने प्रोजेक्ट को देखा जहाँ यह समस्या है और पाया कि मैं भी इसी तरह करता हूँ। यह पुराना कोड होना चाहिए। मैं इसे अपने userMenu.txt फ़ाइल से हटा दूंगा और ऊपर दिए गए कोड से इसे संपादित करके हटा दूंगा।
मैं इसे उन सभी एम्बेडेड चरित्र टैग के लिए + जोड़ने वाले कोड से बदल दूंगा।

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

---

मैं बीच में आकर यह कहूँगा कि \wj मार्करों को बार-बार खोलने/बंद करने की यह प्रणाली मुझे हमेशा से दिए गए कारणों के लिए परेशान करती रही है। जाँचों (checks) को पास करने के लिए मैंने मार्करों को ठीक किया है, लेकिन टीम में कोई भी अन्य व्यक्ति यह समझने में सक्षम नहीं है कि \wj मार्कर को बंद और फिर से खोलना कब और क्यों आवश्यक है। या निस्टिंग (nesting) क्यों आवश्यक है (या ठीक-ठीक कब यह आवश्यक है और कब नहीं)।

मेरा मानना है कि PT का अंतिम लक्ष्य यह होना चाहिए कि सामान्य उपयोगकर्ता इसे उच्च स्तरीय सहायता स्टाफ द्वारा लगातार समायोजन (tweaking) के बिना उपयोग कर सकें। यीशु के वचनों को चिह्नित करना निश्चित रूप से ऐसा कुछ लगता है जो सामान्य उपयोगकर्ता को करने में सक्षम होना चाहिए।

यह तथ्य कि CrazyRocky ने इससे स्वचालित करने के लिए अधिक या कम सफल नियमित अभिव्यक्तियाँ (regex expressions) बनाने में सफल रहे हैं, यह हमें बताता है कि सभी उस चिह्नन (markup) को पीछे की पट्टी पर छिपाना संभव है: यानी USFM फ़ाइलें न्यूनतम रूप से चिह्नित हो सकती हैं और PT या प्रकाशन कार्यक्रमों को प्रोग्राम किया जा सकता है कि वे आवश्यकतानुसार और तुरंत (on the fly) अतिरिक्त जानकारी भर दें।

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