बड़ी TXT फ़ाइल का अनुवाद कैसे करें: एन्कोडिंग, अध्याय और पंक्ति विराम

बड़ी TXT फ़ाइल का अनुवाद करने के लिए, इसे कहीं भी अपलोड करने से पहले तीन चीज़ें तैयार करें। पहला, सुनिश्चित करें कि पाठ सही ढंग से डिकोड हो रहा है और इसे UTF-8 के रूप में सहेजें। दूसरा, हर अध्याय शीर्षक को अपनी अलग पंक्ति में रखें और उसके चारों ओर एक खाली पंक्ति छोड़ें। तीसरा, यदि फ़ाइल निश्चित चौड़ाई पर पंक्तियाँ तोड़ती है, तो उन पंक्तियों को जोड़ दें ताकि प्रत्येक अनुच्छेद एक पंक्ति हो, और अनुच्छेदों के बीच एक खाली पंक्ति हो। फिर पूरी फ़ाइल का अनुवाद करें, और बाद में स्रोत और अनुवाद के बीच अनुच्छेद और अध्याय की गिनती की तुलना करें।

एक सादी पाठ फ़ाइल में कोई शैली, कोई शीर्षक और कोई मेटाडेटा नहीं होता। किसी अनुवाद उपकरण को उसकी संरचना के बारे में जो कुछ भी पता चलता है, वह बाइट्स और पंक्ति विरामों से आता है। यही कारण है कि वही तीन समस्याएँ बार-बार सामने आती हैं: बाइट्स को गलत एन्कोडिंग में पढ़ा जाता है, अध्यायों को सामान्य पंक्तियों से अलग नहीं पहचाना जा सकता, या पंक्ति विराम यह नहीं बताते कि वाक्य कहाँ समाप्त होता है।

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

त्वरित जाँच सूची

चेकर हर पंक्ति पर रिपोर्ट करता है और एन्कोडिंग, बाइट ऑर्डर मार्क, पंक्ति अंत और हार्ड रैपिंग को ठीक करता है। अध्याय शीर्षक और गायब खाली पंक्तियाँ आपको हाथ से ठीक करनी होंगी। रिपोर्ट देखने के लिए python3 check_txt.py inspect yourfile.txt चलाएँ, और पैराग्राफ़ जोड़कर UTF-8 प्रति लिखने के लिए python3 check_txt.py convert yourfile.txt clean.txt --unwrap चलाएँ। इसे केवल Python 3 की आवश्यकता है, और यह मूल फ़ाइल को कभी नहीं बदलता।

चरण 1: एन्कोडिंग सही करें

TXT फ़ाइल बाइट्स का एक क्रम है। एन्कोडिंग वह नियम है जो उन बाइट्स को अक्षरों में बदलता है, और फ़ाइल यह नहीं बताती कि कौन सा नियम इस्तेमाल हुआ था। यदि कोई प्रोग्राम गलत अनुमान लगाता है, तो आपको मोजीबेक मिलता है: ऐसा पाठ जो विकृत है, या इससे भी बुरा, ऐसा पाठ जो ठीक दिखता है लेकिन जो लिखा गया था वह नहीं है।

यहाँ वही चीनी वाक्यांश, 最后一班渡轮 ("अंतिम फ़ेरी"), गलत नियम से पढ़ा गया है। हमने इन्हें Python के अंतर्निहित कोडेक्स से बनाया है, और आप नमूना फ़ाइलों से इन्हें दोबारा बना सकते हैं।

अंतिम पंक्ति खतरनाक है। चीनी के रूप में पढ़े गए जापानी बाइट्स वास्तविक चीनी अक्षर उत्पन्न करते हैं, बिना किसी त्रुटि और बिना � के। एक अनुवाद उपकरण उन्हें खुशी-खुशी अनुवादित करेगा, और परिणाम अच्छे व्याकरण के साथ बकवास होगा।

हमारा चेकर दिखाता है कि आप "यह बिना त्रुटियों के खुल गया" पर भरोसा क्यों नहीं कर सकते। जब हमने इसे Shift_JIS नमूने पर चलाया, तो दो एन्कोडिंग ने पूरी फ़ाइल को एक भी त्रुटि के बिना डिकोड किया:

encoding: unknown (not UTF-8)
these legacy encodings decode without errors; read the previews,
because a wrong one can still produce real-looking characters:
  gb18030  戞堦榖丂嵟屻偺僼僃儕乕
  cp932    第一話　最後のフェリー

केवल दूसरी पंक्ति जापानी है। पहली दुर्लभ चीनी अक्षरों की एक श्रृंखला है जिसे किसी ने नहीं लिखा। GB18030 चीनी नमूने पर, पाँच एन्कोडिंग ने बिना त्रुटियों के डिकोड किया, और उनमें से केवल एक, GB18030, ने अध्याय शीर्षक 第一章 最后一班渡轮 दिखाया। तो नियम सरल है: एन्कोडिंग का निर्धारण पहली पंक्तियों को पढ़कर करें, इससे नहीं कि किसी प्रोग्राम ने शिकायत की या नहीं।

अनुमान आमतौर पर कहाँ गलत होते हैं:

• पुराने Windows सिस्टम या चीनी साइटों से आया चीनी पाठ अक्सर GBK या GB18030 होता है। GB18030 में वह सब कुछ शामिल है जो GBK में है, और WHATWG Encoding Standard, जिसका ब्राउज़र पालन करते हैं, और आगे जाता है: यह कहता है कि "GBK का डिकोडर gb18030 का डिकोडर है।" यदि कोई फ़ाइल GBK है, तो उसे GB18030 के रूप में खोलना काम करता है।
• ताइवान या हांगकांग से पारंपरिक चीनी अक्सर Big5 होती है।
• जापानी अक्सर Shift_JIS, या उसका Microsoft का विस्तारित संस्करण होता है, जिसे Windows और Python cp932 कहते हैं।
• कोरियाई अक्सर EUC-KR होती है।
• NUL बाइट्स से भरी फ़ाइल, या ऐसी फ़ाइल जिसमें हर दूसरा अक्षर खाली दिखता है, आमतौर पर बिना बाइट ऑर्डर मार्क के UTF-16 होती है।

बाइट ऑर्डर मार्क (BOM) फ़ाइल की शुरुआत में एक छोटा अदृश्य कोड होता है जो UTF-8, UTF-16, या UTF-32 की घोषणा करता है। जब यह मौजूद हो, तो उस पर भरोसा करें। वही मानक कहता है कि "बाइट ऑर्डर मार्क किसी भी अन्य चीज़ से अधिक आधिकारिक है।" हमारा चेकर पहले BOM पढ़ता है और केवल तभी अनुमान लगाता है जब कोई न हो।

फ़ाइल को UTF-8 के रूप में सहेजें

एक बार पाठ सही ढंग से पढ़ा जाने लगे, तो उसे UTF-8 के रूप में सहेजें। WHATWG मानक UTF-8 को "यूनिकोड के आदान-प्रदान के लिए सबसे उपयुक्त एन्कोडिंग" कहता है, और यह किसी भी अनुवाद उपकरण के लिए सबसे सुरक्षित विकल्प है।

विशेष रूप से अनुवाद के लिए एक दूसरा कारण भी मायने रखता है। लीगेसी एन्कोडिंग केवल अपने ही क्षेत्र के अक्षरों को कवर करती हैं। Shift_JIS में 这 के लिए कोई कोड नहीं है, जो 这是最后一班渡轮 का पहला अक्षर है, और Big5 में भी इसके लिए कोई कोड नहीं है, क्योंकि यह एक सरलीकृत चीनी अक्षर है। Windows-1252 सिरिलिक को संग्रहीत नहीं कर सकता। यदि अनुवादित फ़ाइल को मूल लीगेसी एन्कोडिंग में वापस लिखना हो, तो लक्ष्य भाषा शायद फ़िट न हो। BookTranslator का TXT अनुवादक कहता है कि वह सामान्य एन्कोडिंग का स्वतः पता लगाता है और अनुवादित फ़ाइल को "इनपुट के समान एन्कोडिंग" के साथ लौटाता है, इसलिए UTF-8 से शुरू करने पर यह प्रश्न ही समाप्त हो जाता है।

आप टेक्स्ट एडिटर में (सही एन्कोडिंग के साथ खोलें, फिर "Save as" UTF-8), macOS या Linux पर iconv -f GB18030 -t UTF-8 in.txt > out.txt के साथ, या चेकर के साथ कनवर्ट कर सकते हैं:

python3 check_txt.py convert book.txt book-utf8.txt --encoding gb18030

यदि फ़ाइल में पहले से � अक्षर हैं, तो नुकसान आपके पास पहुँचने से पहले ही हो चुका है। दोबारा कनवर्ट करने से गायब अक्षर बहाल नहीं होंगे। स्रोत की बेहतर प्रति खोजें।

चरण 2: अध्यायों को खोजना आसान बनाएँ

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

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

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• एक पंक्ति में अकेला एक संख्या या रोमन अंक, जैसे 12 या XII.

inspect चलाएँ और उसने जो शीर्षक पाए उनकी सूची पढ़ें। यदि पुस्तक में 40 अध्याय हैं और चेकर 37 पाता है, तो तीन शीर्षक छिपे हुए हैं: एक पहले वाक्य में मिल गया है, एक अलग शब्द जैसे "Ch. 7" का उपयोग करता है, या एक में उसी पंक्ति में पाठ है। उन तीनों को हाथ से ठीक करें। यह अनुवादित फ़ाइल में समस्या खोजने से कम समय लेता है।

चरण 3: कठोर पंक्ति विरामों को सावधानी से हटाएँ

कुछ TXT फ़ाइलें हर पंक्ति को एक निश्चित चौड़ाई पर तोड़ती हैं, ताकि पाठ एक सादे टर्मिनल या संकीर्ण विंडो में फ़िट हो जाए। PDF से कॉपी किया गया पाठ और OCR आउटपुट मुद्रित पृष्ठ की चौड़ाई पर ऐसा ही करते हैं। इन फ़ाइलों में पंक्ति विराम का अर्थ है "पंक्ति भर गई थी," न कि "वाक्य या अनुच्छेद समाप्त हो गया।"

कठोर रैपिंग को पहचानना आसान है। हमारे कठोर-रैप्ड नमूने में, चेकर ने रिपोर्ट किया:

non-empty lines: 43; longest line: 66 chars; 25 lines within 12 chars of the longest
line breaks inside paragraphs that do not end a sentence: 23
looks hard-wrapped: consider convert --unwrap

समाधान यह है कि प्रत्येक अनुच्छेद के अंदर की पंक्तियों को जोड़ दें और अनुच्छेदों के बीच की खाली पंक्तियों को बनाए रखें। जाल उस पाठ में है जिसके पंक्ति विराम वास्तविक हैं: छंद, गीत के बोल, पत्र, पते, व्यंजन विधियाँ, और सूचियाँ। हमारे नमूने में पाँच पंक्तियों का एक पत्र शामिल है:

My dear Mara,
The key is under the blue pot.
Do not let your uncle sell the boat.
With love, always,
Nonna

एक सीधा "हर एकल पंक्ति विराम को स्पेस से बदल दें" उसे एक लंबी जुड़ी हुई पंक्ति में बदल देता है। चेकर का --unwrap किसी अनुच्छेद को केवल तभी जोड़ता है जब उसकी अधिकांश पंक्तियाँ पूरी चौड़ाई के करीब हों, इसलिए इस पत्र जैसे छोटी-पंक्ति वाले ब्लॉक अछूते रह जाते हैं। हमारे नमूने पर इसने मूल अनरैप्ड फ़ाइल को बिल्कुल, बाइट-दर-बाइट, पत्र सहित फिर से बनाया। अपनी फ़ाइल पर, भरोसा करने से पहले कुछ जोड़े गए अनुच्छेदों और छंद के हर ब्लॉक की जाँच करें।

दो और बातें। जब आप चीनी या जापानी पाठ की पंक्तियों को जोड़ते हैं, तो उनके बीच स्पेस न जोड़ें; चेकर CJK पंक्तियों को, जिनमें CJK विराम चिह्न पर समाप्त होने वाली पंक्तियाँ भी शामिल हैं, बिना स्पेस के जोड़ता है। और यदि आपका पाठ OCR से आया है, तो शब्द पंक्तियों के अंत में हाइफ़न से भी विभाजित हो सकते हैं, जिसके लिए अपने स्वयं के निर्णय चाहिए। हमारी OCR पंक्ति विराम और हाइफ़नेशन ठीक करने की मार्गदर्शिका उसे कवर करती है।

हमने क्या परखा: कठोर-रैप्ड पाठ, पूरा बनाम कटा हुआ

हम जानना चाहते थे कि क्या हार्ड रैपिंग वास्तव में अनुवाद को नुकसान पहुँचाती है, या केवल बेढंगी दिखती है। हमने परीक्षण के लिए 396 शब्दों की एक लघु कहानी लिखी: तीन अध्याय, पंद्रह पैराग्राफ, संवाद, ऊपर दिया गया पत्र, और एक * * * दृश्य विराम। हमने इसे समान शब्दों के साथ दो बार सहेजा: बिना रैपिंग के, जिसमें प्रति पंक्ति एक पैराग्राफ है, और 66 अक्षरों पर हार्ड-रैप्ड, जिसमें 19 के बजाय 43 गैर-रिक्त पंक्तियाँ हैं।

फिर हमने एक स्थानीय मॉडल से इसे सरलीकृत चीनी में तीन तरीकों से अनुवाद करने को कहा, प्रत्येक को तीन बार चलाया:

1. रैप्ड, पूरी फ़ाइल। हार्ड-रैप्ड फ़ाइल एक ही अनुरोध में।
2. अनरैप्ड, पूरी फ़ाइल। अनरैप्ड फ़ाइल एक ही अनुरोध में।
3. रैप्ड, हर 12 पंक्तियों पर कटी। हार्ड-रैप्ड फ़ाइल को हर 12 पंक्तियों पर विभाजित किया गया, प्रत्येक टुकड़े के लिए एक अनुरोध, और उत्तरों को फिर से जोड़ा गया। यह तब होता है जब कोई स्क्रिप्ट या टूल लंबी फ़ाइल को पैराग्राफ के बजाय पंक्ति संख्या के आधार पर विभाजित करता है।

मॉडल LM Studio में Qwen 3.6 27B (Q4_K_M) था, जिसमें थिंकिंग बंद और तापमान 0.3 था, 64 GB मेमोरी वाले Apple M4 Max पर। प्रत्येक अनुरोध में एक ही एक-वाक्य प्रॉम्प्ट का उपयोग किया गया। हमने इसे 28 अक्टूबर, 2026 को चलाया। स्क्रिप्ट run_llm_txt_test.py है, सभी नौ आउटपुट बिना संपादन के प्रकाशित हैं, और results.csv में प्रत्येक रन के लिए एक पंक्ति है।

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

पंक्ति गणना से फ़ाइल काटने ने नुकसान पहुँचाया, हर बार उन्हीं जगहों पर। 12-पंक्ति के टुकड़ों में से तीन वाक्य के बीच में समाप्त हुए। पहला "He pointed with his" पर समाप्त होता है और अगला टुकड़ा "pen at a three-storey building on the corner." से शुरू होता है। अलग से अनुवादित होने पर, दूसरे आधे ने अपना कर्ता खो दिया। दो रनों में यह 她瞥了一眼街角那栋三层楼的建筑, "she glanced at the three-storey building on the corner." के रूप में वापस आया। तीसरे में, यह 随后她重新回到填字游戏上, "then she went back to the crossword." पर समाप्त हुआ। कहानी में, टिकट बूथ में आदमी इशारा करता है और अपने क्रॉसवर्ड पर वापस चला जाता है। सभी तीन रनों में, चीनी पाठक को लगेगा कि यह मारा ने किया।

दूसरा कट, "the careful, slightly old-fashioned hand she had learned at a" और "convent school," के बीच, चीनी वाक्य को 那是她在, "that was where she," पर लटका हुआ छोड़ गया, सभी तीन रनों में (एक रन में एक अतिरिक्त 一 जुड़ गया), और "learned" शब्द गायब हो गया। तीसरे कट ने शटरों वाले वाक्य को दो पंक्तियों में विभाजित किया, और दूसरे आधे ने "painted, not well, but not long ago" को छिलती पुटाई में बदल दिया: दो रनों में 油漆虽已斑驳 और तीसरे में 油漆剥落। और चूँकि टुकड़ों को एकल पंक्ति विराम से जोड़ा गया था, दृश्य विराम से पहले की खाली पंक्ति गायब हो गई, जिसके कारण प्रत्येक रन में 15 के बजाय 14 पैराग्राफ थे। हमारे चेकर ने पैराग्राफ गणना पकड़ ली। यह गलत अक्षर को नहीं पकड़ सका; हमने उसे पढ़कर पाया।

आपकी फ़ाइल के लिए इसका क्या अर्थ है:

• अनरैपिंग आपको उन स्प्लिटरों से बचाती है जो आपके नियंत्रण में नहीं हैं। हर लंबी फ़ाइल कहीं न कहीं विभाजित होती है, चाहे आपकी अपनी स्क्रिप्ट से, चैट विंडो की सीमा से, या जिस टूल पर आप अपलोड करते हैं। यदि पैराग्राफ खाली पंक्तियों से अलग की गई एकल पंक्तियाँ हैं, तो कोई भी उचित स्प्लिटर वाक्य के अंदर के बजाय पैराग्राफ के बीच काट सकता है।
• सबसे बुरी त्रुटियाँ प्रवाहमय थीं। "She glanced at the building" अच्छी चीनी है। एक पाठक प्रत्येक कट पर अजीब पंक्ति विराम और लटके हुए 那是她在 को नोटिस करेगा, लेकिन गलत अक्षर या छिलती पुटाई को गलती के रूप में चिह्नित करने वाला कुछ भी नहीं है। विभाजन बिंदुओं पर त्रुटियाँ पहले अर्थ त्रुटियाँ हैं, स्वरूपण त्रुटियाँ दूसरे।
• यह एक मॉडल और एक छोटी कहानी थी। इतनी छोटी फ़ाइल एक अनुरोध में फिट हो जाती है, इसलिए पूरी-फ़ाइल रनों को कभी कुछ विभाजित नहीं करना पड़ा। एक पूरा उपन्यास विभाजित करना ही पड़ता है, और ठीक तभी चरण 1 से 3 की तैयारी फल देती है। ये फ़ाइलें तैयारी और विभाजन का परीक्षण करती हैं, BookTranslator की अपनी पाइपलाइन का नहीं।

एक छोटी सी टिप्पणी: छह पूरी-फ़ाइल रनों में, मॉडल ने मारा का नाम पाँच में 玛拉 और एक में 马拉 लिखा। प्रत्येक आउटपुट स्वयं के साथ सुसंगत था, लेकिन अलग-अलग अनुरोध एक-दूसरे से सहमत नहीं थे। कई टुकड़ों में अनुवादित एक लंबी पुस्तक के लिए, नामों की एक सूची और उनकी सहमत वर्तनी हर अध्याय को एक पंक्ति में रखती है। हमारी शब्दावली मार्गदर्शिका दिखाती है कि एक कैसे बनाएँ।

चरण 4: अनुवाद करें, फिर गणनाएँ जाँचें

जब फ़ाइल साफ़ हो, तो उसका अनुवाद करना आसान हिस्सा है। आप इसे BookTranslator के TXT अनुवादक पर अपलोड कर सकते हैं, जो .txt, .md, और .mdx फ़ाइलें स्वीकार करता है, कहता है कि यह 300 MB तक की TXT फ़ाइलें संभालता है, और चेकआउट से पहले मूल्य दिखाता है। कोई मुफ़्त पूर्ण अनुवाद नहीं है, लेकिन अपलोड स्वयं आपको लागत बताता है। यदि आप चैट मॉडल या स्थानीय LLM के साथ काम करना पसंद करते हैं, तो फ़ाइल को अध्याय या पैराग्राफ सीमाओं पर स्वयं विभाजित करें और नामों के लिए एक शब्दावली रखें। यदि आपका पाठ सादे गद्य के बजाय Markdown है, तो हमारी Markdown अनुवाद मार्गदर्शिका देखें, क्योंकि Markdown सिंटैक्स के अपने नियम हैं।

अनुवाद के बाद, दोनों फ़ाइलों की तुलना करें:

python3 check_txt.py compare book-utf8.txt book-translated.txt

यदि कोई भी फ़ाइल UTF-8 नहीं है, तो --source-encoding या --translated-encoding जोड़ें। अध्याय जाँच अंग्रेज़ी और चीनी/जापानी शीर्षक पैटर्न जानती है; अन्य लक्ष्य भाषाओं के लिए, स्क्रिप्ट के शीर्ष पर पैटर्न में "chapter" के लिए स्थानीय शब्द जोड़ें।

यह हमारे एक कट-अप रन की रिपोर्ट है:

                            source  translated
paragraphs                      15          14  <- differs
chapter headings                 3           3
non-empty lines                 43          24  <- differs
scene breaks (* * *)             1           1
replacement chars                0           0
source script LATIN characters left in translation: 0

इसे इस तरह पढ़ें:

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

गणनाएँ आपको नहीं बता सकतीं कि अनुवाद सही है या नहीं। प्रत्येक अध्याय का पहला और अंतिम पैराग्राफ पढ़ें, और हर उस जगह के दोनों ओर के पैराग्राफ पढ़ें जहाँ फ़ाइल विभाजित हुई थी। हमारे परीक्षण ने हर गंभीर त्रुटि वहीं पाई।

अक्सर पूछे जाने वाले प्रश्न

मेरी TXT फ़ाइल एक प्रोग्राम में ठीक दिखती है और दूसरे में गड़बड़ क्यों?

दोनों प्रोग्रामों ने अलग-अलग एन्कोडिंग का अनुमान लगाया। एक ने सही अनुमान लगाया। वह एन्कोडिंग खोजें जो पाठ को सही ढंग से दिखाती है, फिर फ़ाइल को UTF-8 के रूप में सहेजें ताकि हर प्रोग्राम इसे एक ही तरह पढ़े।

क्या मुझे अनुवाद से पहले TXT फ़ाइल को EPUB या DOCX में बदलना चाहिए?

केवल तभी जब आप वह चाहते हैं जो वे प्रारूप जोड़ते हैं। स्पष्ट अध्यायों वाली एक साफ़ TXT फ़ाइल जैसी है वैसी ही अच्छी तरह अनुवादित हो जाती है। यदि आप एक विषय-सूची, अध्याय नेविगेशन, और एक ईबुक चाहते हैं जिसे आप किसी डिवाइस पर पढ़ सकें, तो वेब नॉवेल को अनुवाद-योग्य EPUB में बदलने की हमारी मार्गदर्शिका इसे विस्तार से समझाती है।

क्या मैं मिश्रित भाषाओं वाली TXT फ़ाइल का अनुवाद कर सकता/सकती हूँ?

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

उस TXT फ़ाइल का क्या, जो मैंने किसी वेबसाइट से डाउनलोड की है?

जाँच लें कि आपको इसका उपयोग करने का अधिकार है। सार्वजनिक डोमेन की पुस्तकों या आपके द्वारा लिखी गई फ़ाइलों के लिए, ऊपर दिए गए चरण लागू होते हैं। किसी फ़ाइल का एन्कोडिंग या प्रारूप उसके कॉपीराइट के बारे में कुछ नहीं बताता।