+1 मत
1.8k व्यूज़

मैं अपने प्रोजेक्ट में ग्लॉसरी को वास्तव में सेटअप करने की शुरुआत ही कर रहा हूँ, और मेरे पास बहुत सारे सवाल हैं। मुझे आश्चर्य है कि क्या किसी ने कभी "सर्वोत्तम अभ्यास" (best practices) का दस्तावेज़ लिखा है या यह सुझाव दिया है कि उन्होंने चीज़ों को सही ढंग से काम करने के लिए कैसे प्रबंधित किया। मैंने USFM मार्कअप दस्तावेज़ और PT सहायता पढ़ी है, लेकिन वे बहुत सारे सवालों के जवाब नहीं देते।

उदाहरण के लिए, लंबी ग्लॉसरी में लोग इसे अधिक सरल विभाजनों में तोड़ने के लिए अध्याय संख्याओं का उपयोग करते हैं क्या? PT में 998 अध्याय हैं, लेकिन जब मैंने अपनी ग्लॉसरी से गुज़रा और प्रत्येक नए वर्ण के शुरुआत में अध्याय जोड़े, तो नई ग्लॉसरी शब्दावली जोड़ने के लिए Biblical Terms टूल काम करना बंद कर दिया, यह कहते हुए कि कुछ अध्याय सही क्रम में नहीं थे या गायब थे।

अगर आप नई ग्लॉसरी आइटम हाथ से जोड़ते हैं, तो Biblical Term टूल नई ग्लॉसरी आइटम को वर्णानुक्रम में कैसे जोड़ता है? क्या यह आपके हाथ से किए गए संपादनों को पुनर्व्यवस्थित करके उन्हें क्रम में रखेगा?

मुझे यकीन है कि जितना लंबे समय तक मैं इससे काम करूँगा, उतने ही अधिक सवाल होंगे और मुझे आश्चर्य है कि क्या मैं कोई अच्छा संसाधन छूट रहा हूँ जो इन सभी का जवाब देगा।

English से मशीन-अनुवादित
Paratext में द्वारा (1.9k अंक)
फिर से दिखाया गया | 1.8k व्यूज़

10 उत्तर

+2 वोट
सर्वोत्तम उत्तर

अगर आप https://vimeo.com/channels/paratext पर जाते हैं, तो आपको ग्लॉसरी प्रविष्टियों पर दो वीडियो मिलेंगे। मुझे पक्का नहीं है कि क्या सभी सर्वोत्तम अभ्यास निर्दिष्ट किए गए हैं, लेकिन यहाँ कुछ विचार हैं।

  1. कुछ लोग बड़ी ग्लॉसरी के लिए अध्याय संख्याओं का उपयोग करते हैं, लेकिन ध्यान रखें कि प्रकाशन के लिए इन्हें हटाना होगा। और इससे Biblical Terms से लिंकेज विफल हो सकता है। मैं अध्याय संख्याओं का उपयोग न करने की सलाह दूँगा।
  2. प्रिंट प्रकाशन के लिए आपको 20 पृष्ठों की ग्लॉसरी की अनुमति है (यदि यह Wycliffe प्रकाशन है), इसलिए एक विशाल ग्लॉसरी बनाना प्रिंट समय पर समस्या हो सकती है। स्वीकार्य चीज़ों को ध्यान में रखें। स्पष्ट रूप से अन्य उपयोगों (नॉन-प्रिंट) के लिए आप ग्लॉसरी को जितना चाहें उतना बड़ा बना सकते हैं।
  3. Biblical Terms टूल भाषा सेटिंग्स के क्रम के अनुसार ग्लॉसरी को वर्णानुक्रम में रखेगा - इसलिए काम करते समय इसे ध्यान में रखें।
  4. अगर आपके पास ग्लॉसरी में एक प्रविष्टि है, तो आप इसे Biblical Terms टूल में किसी शब्द से जोड़ सकते हैं - वीडियो भाग 2 देखें।
English से मशीन-अनुवादित
द्वारा (9.9k अंक)

मैं अन्य प्रकाशन पथों के लिए नहीं बोल सकता, लेकिन Publishing Assistant 5.1 अब प्रकाशन से पहले ग्लॉसरी से अध्याय संख्याओं को हटाने की आवश्यकता नहीं रखता है।

PADev.

English से मशीन-अनुवादित

यह जानकर अच्छा लगा क्योंकि परिधीय पुस्तकों में बड़ी पुस्तकें Paratext को वास्तव में धीमा कर देती हैं। (मेरे पास ऐसी ग्लॉसरी हैं जो Biblical Terms टूल से स्वतंत्र रूप से बनाई गई थीं, इसलिए मैं लिंकेज के बारे में चिंता नहीं करता।)

क्या PA परिधीय पुस्तकों में अध्याय संख्याओं को अनदेखा करता है? क्या आप प्रत्येक अध्याय में अध्याय लेबल (\cl) जोड़ने की सलाह देंगे?

English से मशीन-अनुवादित

सामान्य रूप से, PA परिधीय पुस्तकों में अध्याय संख्याओं को अनदेखा नहीं करता है; अभी यह केवल ग्लॉसरी में है। PA \cl को अनदेखा नहीं करता है, इसलिए यदि वे जोड़े जाते हैं, तो प्रकाशन से पहले उन्हें हटाना होगा।

PADev.

English से मशीन-अनुवादित

मुझे एक समस्या साझा करने दें जो एक प्रोजेक्ट में उठी। उनके पास शब्दकोश में कई नोट्स थे, जिनमें कोई अध्याय नहीं थे। नोट्स फ़ाइलें इतनी बड़ी हो गईं कि इसका मतलब यह हुआ कि send and receive असंभव हो गया, काफी खराब ब्रॉडबैंड के माध्यम से। इसका कारण यह है कि प्रत्येक नोट शब्दकोश के सभी पाठ से जुड़ा है (चूंकि शब्दकोशों में अध्याय और श्लोक नहीं होते हैं जो सामान्यतः पवित्र ग्रंथ पाठ में नोट किस पाठ से जुड़ा है, उसकी सीमा तय करते हैं)। इसलिए इसका ध्यान रखें। शायद सबसे अच्छा यह होगा कि शब्दकोश में कई नोट्स न लिखें, बल्कि पाठ को Word फ़ाइल में निर्यात करें और वहाँ पाठ पर टिप्पणी करें।

English से मशीन-अनुवादित

क्या यह संभव है कि परिधीय पुस्तकों में अध्याय नंबरों का उपयोग करें और फिर उन्हें initialChanges.txt के माध्यम से हटा दें, ताकि PA इन अध्याय विभाजनों के बारे में कभी न जाने?

English से मशीन-अनुवादित

हाँ, एक बड़ा शब्दकोश वास्तव में Paratext को धीमा कर देता है, इस हद तक कि इसमें कोई संपादन करना लगभग असंभव हो जाता है। कुछ शब्द टाइप करने के बाद, यह बस फ्रीज़ हो जाता है और आपको इसे फिर से प्रतिक्रियाशील होने के लिए काफी देर तक इंतज़ार करना पड़ता है। मेरे पास केवल 8GB का RAM है, लेकिन जब मेमोरी उपयोग की जांच कर रहा था, यह अभी भी दिखा रहा था कि इसके लगभग 50% खाली हैं।

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

इस समस्या को हल करने के लिए कोई समाधान?

English से मशीन-अनुवादित

मेरे पास 32gb की मेमोरी है और मैं भी धीमावट का अनुभव कर रहा था जिससे शब्दकोश बिल्कुल अकार्यशील हो गया।

नोट्स की समस्या ने भी हमें प्रभावित किया। अंत में धीमावट की समस्या इतनी गंभीर थी कि मैंने नोट्स को हटाने का फैसला किया। इसमें काफी समय लगा, लेकिन अंत में यह लाजवाब था।

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

एक और, बहुत अधिक कठिन, विकल्प होगा कि मूल Notes फ़ाइलों को एक टेक्स्ट एडिटर के साथ संपादित करके अध्याय नंबरों को बदलना। यदि आपके प्रोजेक्ट में कई सदस्य हैं तो आप यह सुनिश्चित करना चाहेंगे कि जब आप यह करते हैं तो कोई नोट्स नहीं बना रहा है। और जब नोट्स नए अध्याय में चले जाते हैं तो वे सही स्थान पर जुड़ सकते हैं या नहीं। इसलिए आपको उन्हें अध्याय के शुरुआत में खोजना और बाद में उन्हें फिर से जोड़ना पड़ सकता है। फायदा यह है कि आप मूल नोट्स देख रहे होंगे - आपके द्वारा खुद लिखे सारांश नहीं।

English से मशीन-अनुवादित
0 वोट

मुझे साझा करने के लिए एक 'सर्वोत्तम अभ्यास' है। ग्लॉसरी में \k कीवर्ड मार्कर के उपयोग के तरीके के बारे में सतर्क रहें।

प्रत्येक ग्लॉसरी प्रविष्टि में एक से अधिक \k का उपयोग न करें।

हमने प्रारंभ में प्रत्येक प्रविष्टि में एक से अधिक \k का उपयोग किया था, जिसे हमने अपनी सामने की अनुवाद से उत्तराधिकृत किया था, जो 7.5 में ठीक काम करता प्रतीत होता था। लेकिन PT8 में इसने बड़ी मुश्किलें पैदा कीं। उदाहरण के लिए, पसोवर (Passover) के बारे में एक प्रविष्टि में, हमारे पास अन्य उत्सवों या संबंधित कीवर्ड्स के बारे में अतिरिक्त जानकारी भी हो सकती है। इसलिए इन उप-प्रविष्टियों को \k से चिह्नित किया गया था। लेकिन Paratext ने इन्हें नई ग्लॉसरी प्रविष्टियों के रूप में देखा, और क्योंकि ग्लॉसरी स्वतः ग्लॉसरी को वर्णानुक्रम में क्रमबद्ध करती है, जानकारी को इस तरह से पुनः-वर्णानुक्रमित कर दिया गया जिससे यह समझना बहुत कठिन हो गया कि क्या हुआ था। बाद में हमें बताया गया कि हमें इन उप-प्रविष्टियों के लिए किसी अन्य मार्कर का उपयोग करना चाहिए, जैसे \bdit (बोल्ड, इटैलिक)। मुझे पक्का नहीं है कि क्या यह सही है, लेकिन इसने हमें उन समस्याओं से बचने में मदद की जो हम सामना कर रहे थे।

English से मशीन-अनुवादित
द्वारा (1.3k अंक)
+1 मत

अपने उत्तरों के लिए सभी का धन्यवाद।

@Stephen+Katt, मुझे USFM दस्तावेज़ीकरण में \pi# मार्कर के लिए "उप-प्रविष्टियाँ, या द्वितीयक अनुच्छेद(यदि अंतर्वेशन पसंद किया जाता है)" दिखता है। क्या आपने कभी अपने उप-प्रविष्टियों के लिए इसका उपयोग करने पर विचार किया था? यदि नहीं, तो क्या कोई कारण था कि आप उस मार्कर का उपयोग नहीं करना चाहते थे?

Vimeo फ़ाइलों ने बिल्ट-इन PT सहायता दस्तावेज़ों के समान जानकारी कवर की थी।

  • क्या Biblical Terms Renderings विंडो के माध्यम से ग्लॉसरी आइटम जोड़ना अध्याय मार्कर के साथ बिल्कुल काम नहीं करता?
    • क्या कोई इससे बचने के लिए कोई चाल जानता है?
    • अगर मैं Renderings टूल का उपयोग करने के लिए \c मार्कर को \s में बदलने के लिए एक बाहरी संपादक का उपयोग करता हूँ और ग्लॉसरी ब्राउज़ करने के लिए वापस \c में बदलता हूँ, तो क्या कोई संभावित समस्या है जिसे कोई पूर्वानुमान लगा सकता है?
    • जैसे @CrazyRocky ने उल्लेख किया, एक अत्यंत लंबी ग्लॉसरी PT को काफी हद तक धीमा कर देती है।
  • ग्लॉसरी वर्णानुक्रमिक क्रमबद्धीकरण को कैसे और कब लागू करती है?
    • मैंने Language Setting–>Alphabetic Characters डायलॉग में क्रम सेट कर दिया है।
      • लेकिन ग्लॉसरी स्वयं को गलत ढंग से पुनः-क्रमबद्ध कर रही है। यह किसी प्रकार का क्रम निर्धारित कर रही है, बस वह नहीं जो मैंने परिभाषित किया था।
    • मैंने ग्लॉसरी में गलत जगह एक प्रविष्टि हाथ से बनाई है, और यह कभी सही जगह पर नहीं जाती है।
      • फिर मैंने इसे Biblical Term Renderings से जोड़ा, और यह वर्णानुक्रमिक जगह पर चली जाती है।
      • तो क्या वर्णानुक्रमिक क्रमबद्धीकरण केवल BT/Renderings विंडो के माध्यम से काम करता है?
English से मशीन-अनुवादित
द्वारा (1.9k अंक)

हमारे मामले में, हम अलग-अलग अंतर्वेशन वाले अनुच्छेदों की तलाश में नहीं थे। ये 'उप-कीवर्ड्स' पाठ के साथ इनलाइन थे, इसलिए हम वास्तव में केवल इन्हें अन्य कीवर्ड्स की तरह बोल्ड फॉर्मेटिंग चाहते थे ताकि वे उभरकर सामने आएँ। यह मुख्य रूप से इसलिए हुआ क्योंकि हमने एक मौजूदा सामने की अनुवाद से अनुकूलन किया था और हम काम करते-करते चीज़ें समझ रहे थे। \pi# मार्कर काम कर सकता है यदि हमने इन अन्य शब्दों को अपनी तरह की आधिकारिक उप-प्रविष्टि देने का निर्णय लिया। लेकिन मैंने यह देखने के लिए नहीं देखा है कि यह पाठक के लिए कैसे प्रतीत होगा।

English से मशीन-अनुवादित

मैंने ग्लॉसरी में दो अध्याय होने का एक तेज़ी से परीक्षण किया और मैंने Biblical Terms टूल से और सीधे ग्लॉसरी में नए शब्द जोड़ने में सफलतापूर्वक काम किया।

मैंने कभी-कभी कुछ श्लोक संख्याएं जोड़ी हैं (जिन्हें प्रकाशन से पहले हटाना होगा) ताकि ग्लॉसरी में बेहतर खोज की जा सके।

प्रविष्टियाँ पुनः-क्रमबद्ध नहीं होती हैं जब तक आप वास्तव में Biblical Terms टूल में एक ग्लॉसरी प्रविष्टि को समायोजित न करें।

ध्यान दें कि \pi \k…\k* प्रविष्टि को फिर भी क्रमबद्ध करेगा क्योंकि क्रमबद्धीकरण \k…\k* पर होता है, चाहे \k के सामने कोई भी मार्कर हो। और \pi को \pi nl \p में बदल दिया जाएगा ताकि प्रविष्टि \p से शुरू हो।

मैंने यह भी देखा है कि अगर मैं किसी प्रविष्टि के लिए किसी अन्य मार्कर का उपयोग करता हूँ (जैसे \li या \q1), तो जब Biblical Terms टूल उस प्रविष्टि को संपादित करता है या उससे लिंक करता है, तो वह \p में बदल जाता है। इसलिए, मेरी सलाह होगी कि उन्हें \p के रूप में छोड़ दें और यदि आवश्यक हो तो ग्लॉसरी पूर्ण होने पर उन्हें बदल दें।

अगर आप उप-प्रविष्टियों चाहते हैं, तो एक विकल्प यह होगा कि \pi \bdit…\bdit* जैसे कुछ का उपयोग करें ताकि प्रविष्टि सही ढंग से फॉर्मेट हो, लेकिन पुनः-क्रमबद्ध न हो।

ग्लॉसरी के कई रूप हो सकते हैं। मैं मूल जानकारी जगह पर आने तक फॉर्मेटिंग पर बहुत समय न खर्च करने की सलाह दूँगा।

English से मशीन-अनुवादित

मुझे आपकी प्रश्न पसंद आए कि क्रमव्यवस्था कैसे और कब होती है। क्या आपको कोई उत्तर मिला है? क्या आपने पहले से ही परीक्षण किए हैं और और अधिक जाना है?

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

English से मशीन-अनुवादित
+1 मत

मैं anon848905 के सुझाव को पुष्टि करना चाहता हूँ कि ग्लॉसरी पर दो वीडियो देखें। USFM की चर्चा बहुत मूलभूत है, लेकिन वे कुछ कम ज्ञात ग्लॉसरी विशेषताओं को कवर करते हैं। दो चीज़ें जो मेरे मन में आती हैं, वे हैं उन शब्दों से निपटना जिनमें कई उपसर्ग हैं, और पाठ में वर्तनी परिवर्तन जैसे कुछ के कारण टूटने के बाद Biblical terms टूल और ग्लॉसरी के बीच लिंक को पुनः स्थापित करना।

मैं आपको Katie Barnwell के ग्लॉसरी बनाने पर छोटे लेख को पढ़ने के लिए भी प्रोत्साहित करूँगा, जो Translator’s Workplace में उपलब्ध है। उनके पास यह तय करने के लिए अच्छा सलाह है कि ग्लॉसरी में क्या और क्या नहीं जाना चाहिए। मैंने उनके काम को विस्तारित करना शुरू कर दिया है और Paratext की ग्लॉसरी की ओर को मिला दिया है, लेकिन मैंने उस प्रोजेक्ट को पूर्ण नहीं किया है। वास्तव में, अगर किसी को बाइबल ग्लॉसरी की शब्दकोश विज्ञान की ओर से अन्य लेखों या सामग्रियों के बारे में पता है, तो मैं उन्हें सुनकर आभारी रहूँगा।

English से मशीन-अनुवादित
द्वारा [Expert]
(2.9k अंक)
0 वोट

लोग अपनी ग्लॉसरी को कैसे तोड़ते हैं ताकि इसे पढ़ना और चीज़ें खोजना आसान हो? क्या आप प्रत्येक नए वर्ण की घोषणा करने के लिए \s मार्कर का उपयोग करते हैं? जैसे \s A, \s B, \s C, आदि।

यदि हाँ, तो यह स्वतः वर्णानुक्रमिक क्रमबद्धीकरण के साथ कैसे काम करता है? मैं आश्चर्य कर रहा हूँ क्योंकि मेरे \s मार्कर में से कुछ ने किसी बिंदु पर क्रम बदल दिया जब वर्णानुक्रमिक क्रमबद्धीकरण लागू हुआ।

English से मशीन-अनुवादित
द्वारा (1.9k अंक)

मेरी समझ यह है कि सेक्शन शीर्षकों को प्रिंटिंग के ठीक पहले जोड़ना सबसे अच्छा है। वे नई प्रविष्टियों के वर्णानुक्रमिक क्रमबद्धीकरण में बाधा डालते हैं।

English से मशीन-अनुवादित

मैं एक प्रोजेक्ट के साथ काम करता हूँ जहाँ अंश (मान लीजिए एक बार में एक बाइबल पुस्तक) पढ़ने के ऐप्स के रूप में प्रकाशित किए जा रहे हैं। इसलिए जबकि हम सर्वोत्तम प्रथाओं पर चर्चा करते हैं, हमें उम्मीद है कि हम ऐसे वर्कफ्लो खोजेंगे जिनके लिए प्रत्येक पुस्तक के प्रकाशन के लिए बहुत सारी मैनुअल ट्वीकिंग की आवश्यकता नहीं होती (यह मानते हुए कि हम शब्दकोश को फ़िल्टर कर सकते हैं और हमेशा प्रत्येक रीडिंग-ऐप के साथ एक प्रासंगिक शब्दकोश रख सकते हैं)।

यदि स्थायी सेक्शन हेडिंग्स या अध्यायों और नई प्रविष्टियों की स्थिर वर्णक्रमीय क्रमव्यवस्था का कोई तरीका हो सकता है, तो यह एक सहायक सुधार होगा।

English से मशीन-अनुवादित
0 वोट

एक अच्छा शब्दकोश (glossary) अनेक ऐसे पाठकों के लिए पवित्र ग्रंथ को समझने की कुंजी है जो पहली बार पढ़ रहे हैं और जिनके पास अन्य सहायता नहीं है।
सभी का धन्यवाद। मुझे यह थ्रेड बहुत प्रसन्नता दे रहा है, जिसमें "मुझे भी ऐसा ही लगता है" जैसी चिंताएँ हैं और पहले से ही अच्छे सुझाव मौजूद हैं।

मेरा इरादा था कि मैं 'कैसे करें' से जुड़े कुछ प्रश्न लिखूँ और शायद कुछ सुविधा-अनुरोध (feature requests) भी, लेकिन यह कुछ दिन जल्दी हो गया है।

प्रिय सभी, शब्दकोश की संरचना से जुड़े ये प्रश्न वास्तव में बहुत महत्वपूर्ण हैं। क्यों?

कृपया उन सभी गैर-सार्वजनिक परियोजनाओं पर विचार करें, जिनके पास फोरम में बोलने वाले प्रतिनिधि (spokespeople) अक्सर नहीं होते। एक आधुनिक पाठक किसी अन्य धर्म से हो सकता है। वह शायद प्ले स्टोर (Play Store) पर एक पवित्र ग्रंथ ऐप ढूंढ रहा है और एक जिज्ञासु के रूप में पहली बार पढ़ रहा है।

इसलिए हमें एक पूर्ण और उपयोगकर्ता-अनुकूल शब्दकोश की आवश्यकता है:

  • हमें मुख्य पाठ से सबसे प्रासंगिक शब्दकोश प्रविष्टि (glossary entry) तक क्लिक करने योग्य लिंक चाहिए

  • हमें एक विकल्प चाहिए ताकि एक शब्दकोश प्रविष्टि से दूसरी शब्दकोश प्रविष्टि तक संदर्भ दिया जा सके, यह भी क्लिक करने योग्य लिंक के माध्यम से

PT8 में पहले से ही शानदार टूल्स और मजबूत संरचनाएँ हैं, अर्थात् अध्याय, श्लोक और क्रॉस-रेफरेंस। लेकिन शब्दकोश इनका उचित उपयोग नहीं कर रहा है और कुछ अन्य उपयोगकर्ताओं ने अध्यायों और श्लोकों के साथ हैकिंग (hacks) की कोशिश की है।

मैंने स्वयं अध्याय बनाने की कोशिश की और त्रुटि संदेश (error messages) मिले: अध्यायों में केवल अंक और संख्याएँ हो सकती हैं। क्यों? यदि आप इस सीमा को हटा दें (कृपया), तो हम सबसे मजबूत संरचना "अध्याय" का उपयोग कर सकते हैं और उन्हें हमारे वर्णमाल के अक्षरों से जोड़ सकते हैं। यहाँ एक बड़ा खतरा है: यदि आप इस विचार की अनुमति देते हैं, तो अन्य उपयोगकर्ता LUK अध्याय को "5" कह सकते हैं, LUK अध्याय को "पाँच" कह सकते हैं। यह बहुत बुरा होगा। मुझे कारण नहीं पता, लेकिन शायद यह बुरा है, यह नेविगेशन टूल्स को तोड़ सकता है। इसलिए "गैर-शब्दकोश पुस्तकों में अवैध अध्याय संख्याओं" के बारे में एक और जाँच टूल की आवश्यकता उभर सकती है।

हमें शब्दकोश प्रविष्टियों के बीच तुरंत लिंक की आवश्यकता क्यों है:

हमारी व्याकरण में हमारे संज्ञाओं के लिए वर्ण-प्रारंभिक स्थिति (word-initial position) में वर्ग-चिह्न (class-markers) होते हैं। इसलिए एक प्रविष्टि के एकवचन और बहुवचन एक-दूसरे से बहुत दूर होते हैं: S_priest P_priest के पास नहीं है।

हम अपना शब्दकोश इस प्रकार लिखते हैं कि जिस "शब्द की व्याख्या की आवश्यकता है" का पाठ में सबसे सामान्य रूप, हमारे शब्दकोश के लिए मुख्य शब्द (key-term) होता है। इसलिए उदाहरण के लिए "farisees" (फरीसी) को पाठक अक्सर बहुवचन में देखते हैं, इसलिए हमारा विवरण "P_pharisee" के तहत सूचीबद्ध है। लेकिन कुछ पाठक शायद मैन्युअल रूप से "S_pharisee" पर जाएँगे और तब हमें एक लिंक चाहिए। क्योंकि हमारा वर्ग-तंत्र इतना समृद्ध है कि एक स्थानीय बोलने वाला भी एकवचन से यह नहीं बता सकता कि बहुवचन कैसे बनाया जाता है, कई विकल्प होते हैं। अब तक मैं केवल एक विशेष तीर-प्रतीक (arrow-symbol) और वह अन्य शब्दकोश शब्द लिख रहा हूँ जिसका मैं संदर्भ देना चाहता हूँ, और उपयोगकर्ता को मुख्य प्रविष्टि खोजने के लिए स्वयं नेविगेट करना पड़ता है।

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

हमारा शब्दकोश बड़ा हो रहा है। 20 छपी पृष्ठों की सीमा हमारे पठन ऐप्स पर लागू नहीं होती। हमें अपने सामान्य कार्य के लिए अपने शब्दकोश में नेविगेशन करने में भी मदद की आवश्यकता है, केवल ऊपर और नीचे स्क्रॉल करने में बहुत समय लगता है। अध्यायों और श्लोकों की मौजूदा संरचनाओं का उपयोग करने का एक और कारण, क्योंकि उनमें, हमारे पास प्रत्येक PT8 विंडो के ऊपर स्थिर नेविगेशन टूल्स हैं, और कुछ उपयोगकर्ता उनके कीबोर्ड-शॉर्टकट भी जानते हैं।

एक और सुविधा जिसकी हमें आवश्यकता है, प्रत्येक शब्दकोश आइटम पर किए गए कार्य के अनुवर्ती (follow-up) का एक तरीका है। मुझे लगता है कि आप इसे project-progress कहते हैं। कृपया हमारे काम करने के तरीके पर विचार करें:

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

तो शब्दकोश प्रविष्टियों में project-progress और जाँच-टूल्स लागू करने के उद्देश्य से वर्चुअल बैच-संख्याओं या वर्चुअल-एडमिन-अध्यायों जैसी कुछ चीज़ होनी चाहिए। चूंकि हम उन्हें वर्णानुक्रम में नहीं लिखते, और नई प्रविष्टियाँ लगातार जोड़ी जा रही हैं, इस समय ट्रैक करने के लिए कुछ नहीं है। यदि जल्द कुछ नहीं निकलता, तो मुझे एक और निजी मार्कर बनाने और हमारे सिद्ध "stages" और "tasks" पर आधारित एक स्थिति-पंक्ति (status-line) का आविष्कार करने की आवश्यकता होगी, लेकिन इसे व्यक्तिगत शब्दकोश-प्रविष्टियों पर लागू किया जाएगा।

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

कृपया इस प्रतिक्रिया पर आनंदित हों: मेरी टीम के सहकर्मी पिछले सप्ताह शब्दकोश-प्रविष्टियों बनाने की एक सत्र से बहुत खुश लौटे। स्थानीय अनुवादक को कड़ी मेहनत करनी पड़ी और POSS_head को कई नए अवधारणाओं के चारों ओर संभालना पड़ा। लेकिन अंत में PRO ने कुछ ऐसा कहा जैसे "यह बहुत अद्भुत है, हम बहुत कुछ सीख रहे हैं और चीज़ें अब और अधिक सार्थक लगती हैं"। मज़ेदार (या दुखद) बात यह है कि यह कार्य सत्र तब हुआ जब मुख्य पाठ का अध्याय पहले से ही अनुवादित हो चुका था, इसलिए सभी शब्दों और अवधारणाओं की व्याख्या पहले ही कर दी जानी चाहिए थी। लगता है शब्दकोश-कार्य हमारी पूरी टीम के लिए एक मिनी बाइबल-स्कूल बन रहा है।

मेरा अनुमान है कि - यदि हम एक अलग तंत्र का आविष्कार करने के बजाय मौजूदा संरचनाओं को देखें - अधिक कार्यात्मक शब्दकोश के लिए अधिकांश कार्य पहले से ही हो चुके हैं। यह उतना ही सरल हो सकता है कि अध्यायों और श्लोकों को केवल संख्यात्मक के बजाय अल्फा-न्यूमेरिक (alpha-numeric) होने की अनुमति दी जाए (और当然, अवांछित पार्श्व प्रभावों की जाँच की जाए)। हम टेस्टर के रूप में मदद करने के लिए तैयार हैं, क्योंकि यह महत्वपूर्ण है।

इस थ्रेड में सभी विचारों और प्रसंस्करण के लिए धन्यवाद, मैं इसे उत्सुकता से देखता रहूँगा।

English से मशीन-अनुवादित
द्वारा (934 अंक)

टिम,

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

अनेक अनुवाद कार्यों की जाँच और नियमित रूप से संशोधन किया जाना चाहिए, केवल शब्दकोशों का नहीं। Project Plan Feature अक्सर बहुत रैखिक (linear) होता है, लेकिन चक्रीय कार्यों को योजना में सावधानीपूर्वक शब्दों जैसे draft, revision 1, revision 2 आदि का उपयोग करके रखा जा सकता है। यदि शब्दकोश बनाने के अलग-अलग चरणों का प्रबंधन करना आपके लिए महत्वपूर्ण है, तो आप अपनी योजना में कई स्पष्ट चरण जोड़ सकते हैं। उदाहरण के लिए, Drafting चरण में एक कार्य "identify and mark words that may need a glossary entry" हो सकता है। विवरण फ़ील्ड में आप अधिक विस्तृत निर्देश दे सकते हैं जैसे "पाठ में मुख्य शब्दों (headwords) को \w…\w* मार्करों के साथ चिह्नित करें या Bible terms टूल से एक शब्दकोश प्रविष्टि बनाएं, लेकिन परिभाषा का ड्राफ्ट न बनाएं।"

Team Checking चरण में आप "team reviews the terms marked for the glossary" जैसे एक कार्य जोड़ सकते हैं और विवरण में कह सकते हैं "टीम ड्राफ्टर द्वारा शब्दकोश के लिए चिह्नित किए गए शब्दों को स्वीकार या अस्वीकार कर सकती है और ड्राफ्टर द्वारा छूटे हुए शब्दों को जोड़ सकती है।"

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

आप सही कह रहे हैं कि parallel passage tool या interlinearizer के glosses की तरह स्वचालित जाँचें (automated checks) नहीं हैं। यदि यह आपके लिए महत्वपूर्ण है, तो आप parallel passages tool में मौजूद स्थिति जाँच बॉक्स (status check box) के लिए एक सुविधा अनुरोध (feature request) बना सकते हैं। एक बार जब टीम को लगता है कि मूल्यांकन किए जा रहे parallel passages उचित रूप से समानांतर हैं, तो एक टीम सदस्य छोटे बॉक्स को चेक कर देता है जो यह दर्शाता है कि कार्य पूर्ण है। इसी तरह, यह किसी भाषा के बोलने वाले के निर्णय की आवश्यकता होती है कि यह कहने के लिए कि एक शब्दकोश प्रविष्टि पूर्ण है या नहीं, इसलिए pass/fail check box वह एकमात्र तंत्र है जो मैं सोच सकता हूँ जो इस मामले में उपयोग किया जा सकता है।

English से मशीन-अनुवादित

जेस, इसमें आपके इनपुट के लिए धन्यवाद।

हालाँकि, आपकी Project Plan के लिए वर्णित चीज़ अभी PT8 में काम नहीं करती है (या मैं कुछ छूट रहा हूँ)। Project Plan अध्यायों द्वारा संरचित होता है। और हमारे शब्दकोश प्रविष्टियों में कुछ भी (जैसे एक status-tag) नहीं है जिससे हम उन्हें किसी विशिष्ट अध्याय को "assign" कर सकें। हम कुछ ऐसा कह सकते हैं जैसे "mustard-seed पहली बार LUK 15 के संदर्भ में मिला और फिर लिखा गया"। लेकिन जब हम अपने Project Plan पर काम करते हैं, तो उन सभी शब्दकोश प्रविष्टियों को सामने लाने का कोई तरीका नहीं है जो किसी विशेष अध्याय से "संबंधित" हैं।

दूसरी ओर, Biblical Terms विंडो में, मैं आसानी से किसी विशेष श्लोक, अध्याय या पुस्तक के लिए सभी ग्रीक शब्दों को सामने ला सकता हूँ। इसलिए हम आपसे सहमत हैं, लेकिन हमारे पास टूल्स नहीं हैं। या बल्कि ऐसा लगता है कि यह थ्रेड विचारों के संग्रह में बदल रहा है - जो बाद में एक बहु-उपयोगकर्ता सुविधा अनुरोध (multi-user feature request) में बदल सकते हैं। अभी बहुत जल्दी है, मैं अभी भी विचारों का संग्रह कर रहा हूँ और देख रहा हूँ कि अन्य उपयोगकर्ता क्या कर रहे हैं। फिर से धन्यवाद।

English से मशीन-अनुवादित
0 वोट

एक अन्य थ्रेड में, Paratext और Fieldworks को साथ में उपयोग करने का विषय उठा। मैं भविष्य में एक शब्दकोश बनाने वाला टूल (glossary making tool) देखना चाहूँगा जहाँ उपयोगकर्ता Fieldworks डेटाबेस में प्रविष्टियों को टैग कर सकेगा जो Paratext Glossary में आयात (import) किए जाएँगे। यह गतिशील (dynamic) हो सकता है, ताकि जैसे-जैसे Fieldworks में उन शब्दों के लिए डेटा परिष्कृत होता है, शब्दकोश प्रविष्टियाँ अपडेट हो जाएँ। Fieldworks पहले से ही आपको अलग-अलग शब्दकोश बनाने के लिए अपने डेटा के उपसमूह (subsets) लेने की अनुमति देता है; तो क्यों न "Bible Glossary" नामक एक श्रेणी हो और उस श्रेणी को Paratext से जोड़ा जाए। Fieldworks एक बहुत अच्छा शब्दकोश बनाने वाला प्रोग्राम है, हमें उन सभी कार्यों को Paratext में दोहराने के बजाय बेहतर शब्दकोश बनाने के लिए उस शक्ति का उपयोग करना चाहिए।

English से मशीन-अनुवादित
द्वारा [Expert]
(2.9k अंक)
0 वोट

यहाँ राष्ट्रीय अवकाश है, इसलिए कार्यालय में शांत दिन है और हम कुछ शोध और विकास कर सकते हैं:

हमने एक कस्टम मार्कर बनाया और परीक्षण किया कि हम शब्दकोश के प्रत्येक प्रविष्टि की प्रगति-स्थिति को कैसे ट्रैक कर सकते हैं, हमारे Project Plan से हमारे आंतरिक कोड का उपयोग करके।

बाद में, हम शब्दकोश-प्रविष्टियों को प्रगति ट्रैकिंग के लिए वर्चुअल अध्याय या बैच-नंबर सौंपने की अवधारणा को आज़माना चाहते हैं।

दुर्भाग्यवश, नीला “progress” आइकन हमारे शब्दकोश में काम करते समय दिखाई नहीं देता। और भी बदतर, जब विंडो खोलने की कोशिश की (कोड देखने के लिए), मुझे बस यह काफी कठोर संदेश मिला:

वर्तमान पुस्तक (GLO) प्रोजेक्ट प्लान में नहीं है। चूंकि यह एक पवित्र ग्रंथ पुस्तक नहीं है, इसे प्रोग्रेस प्लान में जोड़ा नहीं जा सकता।

तो पिछले कुछ दिनों से हम यहाँ चर्चा कर रहे हैं कि शब्दकोश पर काम करने का सबसे अच्छा तरीका क्या है और अब PT8 मुझे बता रहा है कि हम गुणवत्ता नियंत्रण और प्रगति ट्रैकिंग भी नहीं कर सकते। यह当然 कोई बग नहीं है, लेकिन कृपया पुनर्विचार करें।

मुझे ऐसे प्रोजेक्ट्स के बारे में पता है जहाँ सलाहकार प्रकाशन से पहले शब्दकोश की जांच करते हैं (पवित्र ग्रंथ की तरह नहीं, लेकिन समान), क्योंकि यह उसी पुस्तक में बाहर जाता है और पाठकों के मुख्य पाठ के समझ पर प्रभाव डालता है (चाहे अच्छा हो या बुरा)। तो तकनीकी स्तर पर प्रगति- और गुणवत्ता-ट्रैकिंग को ब्लॉक करने का क्या कारण है? कृपया उन लोगों का पुनर्विचार करें जो नीतियाँ बनाते हैं।

English से मशीन-अनुवादित
द्वारा (934 अंक)

बस यह जानने के लिए कि इस निर्णय के पीछे तर्क क्या है:
शब्दकोश, अतिरिक्त पुस्तकें, आदि में आमतौर पर पवित्र ग्रंथ पुस्तकों की तुलना में अलग (कभी-कभी बहुत अलग) चरणों का सेट होता है जिससे गुजरना होता है। चूंकि Assignments and Progress केवल पूरे प्रोजेक्ट के लिए एक प्लान निर्दिष्ट करने की अनुमति देता है (अर्थात वे चीज़ें जो आप हर पुस्तक के लिए करते हैं), आपको गैर-पवित्र ग्रंथ पुस्तकों के लिए अलग चरण जोड़ने में सक्षम बनाने के लिए, यह पवित्र ग्रंथ पुस्तकों के लिए बाकी चरणों को क्लटर कर देगा और आपको संभवतः उन पुस्तकों में चीज़ों को चेक ऑफ करने के लिए मजबूर होना होगा जो कभी नहीं की जाएंगी।

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

English से मशीन-अनुवादित

@anon291708 को कारणों और पृष्ठभूमि देने के लिए धन्यवाद। मैं सहमत हूँ कि शब्दकोश को जांच के अलग चरणों की आवश्यकता है।

मैं केवल इस बात से चौंका कि PT8 किसी भी प्रकार की जांच की अनुमति नहीं देता Project Plan के माध्यम से, यह जांच विंडो को खोलने से भी इनकार कर देता है (इसलिए हम अपनी मैनुअल स्थिति ट्रैकिंग के लिए अपने संदर्भ देख भी नहीं सकते, जबकि हमारा कर्सर शब्दकोश “पुस्तक” के अंदर है।)

Project Plan टूल शक्तिशाली है और हम आसानी से कुछ समय खर्च कर सकते हैं और आवश्यक कस्टम टास्क के साथ एक कस्टम स्टेज लिख सकते हैं। लेकिन चूंकि टूल पूरी तरह लॉक है, हम इसे बिल्कुल नहीं उपयोग कर सकते।

प्रोग्रेस टूल बिल्कुल नया है। और हमें यह सामान्य पुस्तकों के लिए बहुत पसंद है: हम कागज़ पर सभी टास्क के लिए ट्रैक रखते हैं जो एक पूरे अध्याय से कम कवर करते हैं। और फिर जब एक पूरा अध्याय पूरा हो जाता है, तब हम PT में बॉक्सों पर टिक लगाते हैं। (यह कार्यालय मुख्य रूप से फ्री लैंसर्स से बना है जो तब आते हैं जब वे समय पाते हैं।) इसलिए हम संदर्भों की एक नंबरिंग प्रणाली का उपयोग करते हैं ताकि कागज़ पर आसानी से पता चले कि कौन सा टास्क कौन सा है।

तो जब मैं आपको फीडबैक देता हूँ, कृपया ध्यान में रखें कि हमें यह पसंद है और हम इसकी सराहना करते हैं। फिर भी, कम लॉकिंग-अप के साथ यह अधिक उपयोगी हो सकता है - यह इस बात पर निर्भर करता है कि अन्य उपयोगकर्ता अन्य प्रोजेक्ट्स के लिए क्या पुष्टि करते हैं या अप्रासंगिक घोषित करते हैं।

मुझे याद है कि पुराने PT7 में हमारे पास Project Progress में केवल तीन या चार टास्क परिभाषित थे और मैंने पाया कि हम इसे कस्टमाइज़ कर सकते हैं ताकि अधिकतम 8 टास्क हों। लेकिन हमने कभी भी अपने सभी स्थानीय टास्क की रिपोर्टिंग को बस 8 चरणों में समेटने में सफलता नहीं पाई, इसलिए रिपोर्टिंग एक अफरा-तफरी थी। फिर से: हम नए टूल की सराहना करते हैं, इसमें इसका सारा संभावना है, इसलिए हम इसे अपनी वास्तविकता के साथ बेहतर ढंग से फिट करना चाहते हैं।

जब हम PT8 पर माइग्रेट हुए और हमने Project Plan टूल को पहली बार देखा, तो हमें इसकी पूर्णता पसंद आई और हम अवधारणा की कठोरता और प्रस्तावित उदाहरण-प्लान्स के बारे में घबरा गए। जैसा कि आप कहते हैं “केवल पूरे प्रोजेक्ट के लिए एक प्लान निर्दिष्ट करने की अनुमति देता है”। इसलिए हमने लगभग एक घंटा खर्च किया उन सभी “can only start this task nnnn after task mmmm has been completed” को अन-क्लिक करने में। क्योंकि हमारी स्थानीय स्थितियों और टीम और हमें बीमारियों, अनुपस्थितियों, बिजली कटौती, आदि के लिए अनुमति देने की आवश्यकता के लिए यह पूरी तरह असंभव था। वह प्रोजेक्ट जहाँ मेरे हाथ PT में हैं, वह एक परिपूर्ण प्रोजेक्ट नहीं है और हम एक परिपूर्ण प्लान द्वारा मजबूर होने के बजाय बदसूरत सच की रिपोर्ट और रिकॉर्ड करने को पसंद करते हैं क्योंकि कोई बॉक्स “लॉक अप” था।

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

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

अगला मैं वर्चुअल अध्यायों या बैच-नंबरों के साथ प्रयोग करना चाहता हूँ ताकि शब्दकोश प्रविष्टियों के सेट्स के ट्रैक रख सकें जो एक कार्य-दिन में एक साथ काम किए जाते हैं। इसलिए कृपया आधिकारिक PT रोड-मैप के बारे में हमें सूचित रखें, ताकि जब अतिरिक्त पुस्तकों के ट्रैकिंग के लिए “वास्तविक टूल्स” तैयार हों, हम वहाँ माइग्रेट कर सकें।

English से मशीन-अनुवादित
0 वोट

गवाही: मैंने एक शब्दकोश को “कोई संरचना नहीं” से “33 अध्यायों” में परिवर्तित किया है, एक भाषा के लिए जिसके वर्णमाला में 33 अक्षर हैं। उनमें से कुछ अक्षर कभी भी शब्द-आरंभिक रूप से नहीं आ सकते हैं, इसलिए वे अध्याय खाली रहेंगे।

PT8 इस नए सेटअप के साथ बहुत अच्छा काम करता प्रतीत होता है। नए शब्दकोश प्रविष्टियाँ - जैसा कि Key Terms विंडो से बनाया गया - अभी भी वर्णक्रमीय रूप से ठीक वहाँ क्रमबद्ध हो जाती हैं जहाँ उन्हें होना चाहिए। मैंने कोई बुरा पार्स-प्रभाव नहीं देखा है और टीम ने अभी तक शिकायत नहीं की है।

यह एक और दुखद उदाहरण है जहाँ मनुष्य को अपने कंप्यूटर-टूल के अनुकूल होना पड़ता है; PT8 \c के बाद केवल शुद्ध संख्यात्मक-अंकों को ही स्वीकार करता है - इसलिए मैंने टीम के लिए एक वर्णमाला-चार्ट बनाया ताकि वे शब्दकोश प्रविष्टियों को तेजी से देख सकें: क्या आपको “sh” से शुरू होने वाला शब्द चाहिए?: अध्याय 28 पर जाएं। फिर भी यह पुराने कई स्क्रीन-लंबे असंरचित शब्दकोश से बहुत बेहतर है।

@anon848905 को धन्यवाद जिन्होंने - मुझे विश्वास है - इस थ्रेड में डमी “अध्याय” बनाने के बारे में सबसे पहले साझा किया था।

English से मशीन-अनुवादित
द्वारा (934 अंक)
0 वोट

@anon716631 @mnjames

क्या आपने इस धीमावट की समस्या के बारे में Paratext को फीडबैक सबमिट किया है? शायद जब आप ऐसा करते हैं तो आप शब्दकोश (और शब्दकोश में Project Notes) के कार्य करने के तरीके में परिवर्तनों की अपनी आवश्यकता का विस्तार कर सकते हैं।

English से मशीन-अनुवादित
द्वारा [Moderator]
(2.1k अंक)

मेरा मानना था कि यह समस्या पहले से ही डेवलपर्स को पता थी, लेकिन मैंने अब एक बग रिपोर्ट भेज दी है।

English से मशीन-अनुवादित

संबंधित प्रश्न

0 वोट
6 उत्तर 998 व्यूज़
हमारे पास एक छोटी ग्लॉसरी है (वर्तमान में 1 पेज), और हम बैक ट्रांसलेशन प्रदान करने के लिए इंटरलिनियर का उपयोग ... इंटरलिनियर स्वीकार करता है? इसके लिए सर्वोत्तम अभ्यास क्या है?
anon542642 294 पूछा गया फ़रवरी 21, 2022
0 वोट
6 उत्तर 867 व्यूज़
चूंकि जो भी चित्र सम्मिलित किए जाएंगे वे send/receive के माध्यम से भेजे जाएंगे, इसलिए चित्रों के साथ काम करते समय ... चित्र जोड़ने की इच्छा दर्शाता है। क्या कोई बेहतर तरीका है?
drwww 448 पूछा गया अक्टूबर 1, 2018
0 वोट
0 उत्तर 135 व्यूज़
I'd like to suggest that it's best practice to make a snapshot of a project by either making a back up, or (preferably ... doesn't fint the aims of this site, then please tell me!)
wdavidhj 1.4k पूछा गया दिसंबर 6, 2017
Paratext में
0 वोट
1 उत्तर 104 व्यूज़
मैंने पुरातत्त्विक अभिव्यक्तियों टूल (Biblical Renderings Tool) में शब्दकोश प्रविष्टियों वाले पुरातत्त्विक शब्द खोजने की कोशिश की है, ... हैं (जैसे कि दिखाने के लिए एक कॉलम)?
KR 151 पूछा गया मार्च 12
0 वोट
1 उत्तर 20 व्यूज़
मैंने "शब्दकोश सर्वोत्तम प्रथाएं" (https://support.bible/3952/glossary-best-practices?show=3952#q3952) पढ़ी है। वहाँ दी गई ... संभव है, तो मैं इसकी सराहना करूँगा! धन्यवाद, पॉल
Paul 642 पूछा गया अक्टूबर 21, 2025
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
They devoted themselves to the apostles’ teaching and to fellowship, to the breaking of bread and to prayer.
Acts 2:42
3,045 प्रश्न
6,005 उत्तर
5,671 टिप्पणियाँ
2,026 उपयोगकर्ता