Question

PT9.5 में 02BC के प्रबंधन में परिवर्तन हुआ प्रतीत होता है। मैं 02BC को विलोपन (elision) के लिए उदाहरण चिह्न (apostrophe) के रूप में उपयोग कर रहा हूँ। इसे भाषा - सेटिंग्स (Language - Settings) में शब्द-मध्य (word-medial) वर्ण के रूप में परिभाषित किया गया है।

हालाँकि, जाँचें (checks) चलाते समय, paratext इसे एक दीक्रिटिक (diacritic) के रूप में मानता है :

आपकी सलाह क्या है? मैं क्या छोड़ रहा हूँ?
आपकी सहायता के लिए पहले से ही धन्यवाद।

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

Comments

क्या आप यह सत्यापित कर सकते हैं कि 02BC वर्णात्मक वर्ण सेटिंग्स (Alphabetic Character settings) में भी नहीं आता?

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

---

जवाब देने के लिए धन्यवाद Phil। मैं पुष्टि कर सकता हूँ कि 02BC वर्णात्मक सेटिंग्स (Alphabetic settings) में नहीं आता, बस "अन्य वर्ण" (other character) टैब में:

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

---

मेरे अनुभव के अनुसार, Paratext में हमने हमेशा 02bc को एक स्वतंत्र ग्लोटल स्टॉप (glottal stop) के रूप में उपयोग किया है, और SIL तकनीशियनों ने वर्षों से इसकी सिफारिश की है। यहाँ PT Help का एक क्लिप है जो 2022 में इस फोरम में पोस्ट किया गया था ग्लोटल को उदाहरण चिह्न के रूप में?।

मैंने अभी तक PT 9.5 में यह नया व्यवहार नहीं देखा है, लेकिन मेरे अनुभव के अनुसार यह SIL सॉफ्टवेयर के लिए सामान्यतः नया व्यवहार है। PT v 9.4 तक, Fieldworks, Bloom, आदि, LibreOffice (मैं Word के लिए नहीं कह सकता) और PTX Print (मुझे लगता है) ने 02bc को एक अलग वर्ण के रूप में माना है, जो उन भाषाओं में ग्लोटल की भाषाई स्थिति है जिनके साथ मैंने काम किया है, और किसी अन्य ग्लाइफ से जुड़े दीक्रिटिक के रूप में नहीं। मैंने यह माना है कि इसे भाषा के वर्णात्मक इन्वेंटरी (alphabetical inventory) में जोड़ने से इसे एक स्वतंत्र वर्ण के रूप में चिह्नित किया जाता है, भले ही इसकी यूनिकोड श्रेणी "संशोधक अक्षर" (Modifier letter) हो।

यह मुझे थोड़ा चिंताजनक लगता है क्योंकि कई भाषाओं ने व्यापक लाइब्रेरी में 02bc का उपयोग किया है। क्या यह बदलाव हमारे वर्तनी जाँच (spellchecking), बाइबलिकल टर्म्स (Biblical Terms) और अन्य टूल्स में इस वर्ण का उपयोग करने का तरीका बदल देगा? क्या यह पिछले या बाद के ग्लाइफ से जुड़ता है (हमारे मामले में, न तो और न ही, और दोनों में से किसी एक को मानना पाठकों और संपादकों दोनों के लिए भ्रम पैदा करेगा)।

क्या कोई तरीका है कि PT और अन्य आगामी कार्यक्रमों को इसे लेखन प्रणाली की विशिष्टताओं के आधार पर किसी भी तरह से वर्गीकृत करने के लिए मजबूर किया जा सके?

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

---

ऊपर दिया गया वास्तव में इस टिप्पणी का उत्तर है। माफ़ कीजिए कि मैंने इसे गलत जगह पोस्ट कर दिया!

यूनिकोड (Unicode) के अनुसार, 02bc को एक दीक्रिटिक (diacritic) माना जाता है, इसलिए मुझे लगता है कि वर्तमान व्यवहार सही है। मैं अनुमान लगा रहा हूँ कि पिछला व्यवहार एक बग था। मुझे पता नहीं है कि इस समस्या के बारे में हम क्या कर सकते हैं, लेकिन फीडबैक देना निश्चित रूप से आगे बढ़ने का सबसे अच्छा तरीका है।

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

---

जितना मुझे पता है, जो भी बदलाव किया गया है, उसका प्रभाव वर्णों के इन्वेंटरी (Characters Inventory) में वर्ण के प्रदर्शन के तरीके में है। इसका प्रभाव वर्डलिस्ट (Wordlist), बाइबलिकल टर्म्स (Biblical Terms) या अन्य टूल्स में शब्दों के प्रदर्शन पर नहीं होना चाहिए।

अगर आपको वर्तमान जाँच के कोई अन्य प्रभाव दिखें - कृपया इसे रिपोर्ट करें।

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

---

बस कुछ अतिरिक्त संदर्भ और नीचे एक अतिरिक्त प्रश्न: paratext 6 के साथ अधिक गहन जाँचों के आने के साथ, इसका मतलब यह था कि u2019 का उपयोग विलोपन (apostrophe) और बंद उद्धरण चिह्नों दोनों के लिए करने से paratext त्रुटियाँ उत्पन्न करता था। कागज़ पर और स्क्रीन पर हम बिल्कुल ठीक थे, बेशक ;-)। Paratext में त्रुटि संदेशों को हटाने के लिए सलाह दी गई थी कि जिनको विलोपन को चिह्नित करने की आवश्यकता है, उन्हें u02BC का उपयोग शुरू करना चाहिए। ग्लोटल के लिए u02BC का उपयोग मुझे लगता है कि इसका "सामान्य" उपयोग माना जाता है, हालाँकि यूनिकोड की व्याख्या के अनुसार uA78C ग्लोटल के लिए वास्तविक सामान्य वर्णात्मक अक्षर है।
हम Paratext में [C]+02BC के सभी संयोजनों को वर्ण इन्वेंटरी में मान्य स्वीकार कर सकते हैं और इसकी चिंता नहीं कर सकते। लेकिन मैं सोच रहा हूँ कि Flex में, शब्द-मध्य 02BC वाले शब्द को क्या "पहचाना" जाएगा एक नए लीक्सेम (lexeme) के रूप में? इन प्रकार के लीक्सेमों की अनुमति देने वाली भाषा में (flex में), इसका पता लगाना चाहिए (control-D के माध्यम से)।

तो, क्या हमें Paratext में एक नया फीचर चाहिए ताकि paratext उन भाषाओं के बीच अंतर करने में सक्षम हो सके जो 02BC को एक दीक्रिटिक (सही ढंग से, यानी संशोधक) के रूप में उपयोग करती हैं और उन भाषाओं जो 02BC को एक सामान्य अक्षर के रूप में उपयोग करती हैं, या तो ग्लोटल या "प्रतिस्थापित" अक्षर जो उच्चारित नहीं होता है, यानी विलोपन? (एक टिकबॉक्स के साथ: कृपया संकेत दें कि आप 02BC का उपयोग कैसे कर रहे हैं?)

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

Answer 1

02BC को यूनिकोड (Unicode) में एक संशोधक अक्षर (modifier letter) के रूप में परिभाषित किया गया है। मेरा मानना है कि जो हो रहा है, वह यह है कि भले ही आप इसे शब्द-मध्य (word medial) में रख रहे हों, फिर भी इसे एक अक्षर के रूप में माना जाता है और यह अन्य अक्षरों के साथ संयोजन में दिखाई देता है।
कृपया डेवलपर्स को यह एक समस्या के रूप में रिपोर्ट करने के लिए Help > Give Feedback का उपयोग करें।

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

Comments

यूनिकोड (Unicode) में संशोधक अक्षर (Modifier letters) को Paratext के लिए हमेशा दीक्रिटिक (diacritics) माना जाता है। यह हमेशा से मामला रहा है। मुझे यह समझ नहीं आ रहा है कि ऐसा लगता है जैसे 9.4 से 9.5 तक व्यवहार में बदलाव आया है। 

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

---

मेरा मानना है कि यह उन स्थानों में से एक है जहाँ Paratext 9.5 उन चीज़ों की जाँच कर रहा है जो 9.4 में अनिवार्य रूप से जाँची नहीं जाती थीं।

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

---

Foolrunning - मैंने अभी-अभी PT8 की परीक्षा की और देखा कि 02BC अलग है। 9.5 में यह पिछले वर्ण के साथ संयोजित है।

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

---

मैंने थोड़ा गहराई से देखा, और आप बिल्कुल सही हैं। 9.5 में एक बदलाव था जिसका मैंने ध्यान नहीं दिया। 

यूनिकोड (Unicode) के अनुसार, 02BC को एक दीक्रिटिक (diacritic) माना जाता है, इसलिए मुझे लगता है कि वर्तमान व्यवहार सही है। मैं अनुमान लगा रहा हूँ कि पिछला व्यवहार एक बग था। मुझे पता नहीं है कि इस समस्या के बारे में हम क्या कर सकते हैं, लेकिन फीडबैक देना निश्चित रूप से आगे बढ़ने का सबसे अच्छा तरीका है।

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

---

Flex में 02BC से संबंधित सहायता को देखते हुए, हम निम्नलिखित पढ़ते हैं:

02BC संशोधक अक्षर उदाहरण चिह्न (MODIFIER LETTER APOSTROPHE) को यूनिकोड मानक में शब्द-गठन (word-forming) के रूप में परिभाषित किया गया है, इसलिए इसका उपयोग उचित होगा, ....

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

जब हमने 02BC के लिए चयन किया, तब बिल्कुल गोल आकृति थी, जिसने 0027 की तुलना में 02BC के पक्ष में "तौल" झुका दिया। हम चाहते थे कि छपी हुई पवित्र ग्रंथ (और ऐप) में हाथ से लिखा गया कर्ली-टाइप उदाहरण चिह्न हो। हम 0027 पर वापस जा सकते हैं, अगर Charis में एक वैकल्पिक कर्ली ग्लाइफ है, लेकिन इसमें keyman फाइलों में व्यापक रूप से बदलाव की भी आवश्यकता होगी। (मेरा अनुमान है कि कम से कम पूरे पश्चिम अफ्रीका के लिए, जहाँ विलोपन के लिए 02BC का उपयोग सामान्य प्रथा बन गया है)।

0027 के ग्लाइफ सेट को देखते हुए, "बुरे" ' के लिए कोई वैकल्पिक ग्लाइफ नहीं है ... Charis 7.0 दस्तावेज़ीकरण की नीचे दी गई छवि को देखते हुए, ऐसा लगता है कि उदाहरण चिह्न के क्रियान्वयन के तरीके में बदलाव आया है (हालाँकि मैं दस्तावेज़ीकरण में इसका उल्लेख नहीं ढूँढ पा रहा)।

अगर मैं Charis SIL 6.2 और Charis 7.0 की तुलना करता हूँ, तो कोई अंतर नहीं दिखाई देता:

हमारे पाठकों ने कर्ली उदाहरण चिह्न के आदी हो चुके हैं, इसलिए 0027 (अभी भी) एक विकल्प नहीं है। मुझे लगता है कि इस समय विकल्प हैं 1: इस समय के लिए Paratext 9.4 पर वापस जाना। 2: वर्ण इन्वेंटरी में [C]+02BC के सभी संयोजनों को मान्य करने के लिए।
प्रश्न यह बना रहता है कि 9.4 से 9.5 तक बदलाव मध्य 02BC वाले शब्दों के लिए Flex के लिए ब्रिज फंक्शन को प्रभावित करता है या नहीं।

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