چگونه یک فایل 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 نیاز دارد و هرگز فایل اصلی را تغییر نمی‌دهد.

مرحله ۱: کدگذاری را درست کنید

یک فایل TXT دنباله‌ای از بایت‌هاست. کدگذاری قاعده‌ای است که آن بایت‌ها را به کاراکتر تبدیل می‌کند، و فایل نمی‌گوید کدام قاعده استفاده شده است. اگر برنامه‌ای اشتباه حدس بزند، نتیجه mojibake می‌شود: متنی که به‌هم‌ریخته است، یا بدتر، متنی که خوب به نظر می‌رسد اما آن چیزی نیست که نوشته شده بود.

این همان عبارت چینی، 最后一班渡轮 ("آخرین کشتی ferry")، است که با قاعده اشتباه خوانده شده. ما این‌ها را با کدک‌های داخلی Python تولید کردیم و شما می‌توانید آن‌ها را با فایل‌های نمونه بازتولید کنید.

ردیف آخر خطرناک است. بایت‌های ژاپنی که به‌عنوان چینی خوانده شوند، کاراکترهای چینی واقعی تولید می‌کنند، بدون هیچ خطا و بدون �. یک ابزار ترجمه با کمال میل آن‌ها را ترجمه می‌کند و نتیجه nonsense با دستور زبان خوب خواهد بود.

بررسی‌کننده ما نشان می‌دهد چرا نمی‌توانید به «بدون خطا باز شد» تکیه کنید. وقتی آن را روی نمونه 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، سرصفحه فصل 第一章 最后一班渡轮 را نشان داد. پس قاعده ساده است: کدگذاری را با خواندن خطوط اول تعیین کنید، نه با این‌که برنامه‌ای شکایت کرده یا نه.

جایی که حدس‌ها معمولاً اشتباه می‌روند:

• متن چینی از سیستم‌های ویندوز قدیمی یا سایت‌های چینی اغلب GBK یا GB18030 است. GB18030 همه چیزهایی را که GBK پوشش می‌دهد پوشش می‌دهد، و استاندارد رمزگذاری WHATWG که مرورگرها از آن پیروی می‌کنند، فراتر می‌رود: می‌گوید «رمزگشای GBK همان رمزگشای gb18030 است.» اگر فایلی GBK باشد، باز کردن آن به عنوان GB18030 کار می‌کند.
• چینی سنتی از تایوان یا هنگ‌کنگ اغلب Big5 است.
• ژاپنی اغلب Shift_JIS است، یا نسخه توسعه‌یافته مایکروسافت از آن، که ویندوز و پایتون آن را 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 نمی‌تواند سیریلیک را ذخیره کند. اگر فایل ترجمه‌شده باید دوباره با رمزگذاری قدیمی اصلی نوشته شود، ممکن است زبان مقصد جا نشود. مترجم TXT BookTranslator می‌گوید رمزگذاری‌های رایج را به‌طور خودکار تشخیص می‌دهد و فایل ترجمه‌شده را «با همان رمزگذاری ورودی» برمی‌گرداند، بنابراین شروع از UTF-8 این سؤال را کاملاً حذف می‌کند.

می‌توانید در یک ویرایشگر متن تبدیل کنید (با رمزگذاری درست باز کنید، سپس «ذخیره به عنوان» UTF-8)، با iconv -f GB18030 -t UTF-8 in.txt > out.txt در macOS یا لینوکس، یا با بررسی‌کننده:

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

اگر فایل از قبل حاوی کاراکترهای � است، آسیب قبل از رسیدن به شما رخ داده است. تبدیل دوباره کاراکترهای از دست رفته را برنمی‌گرداند. به دنبال نسخه بهتری از منبع باشید.

مرحله ۲: یافتن آسان فصل‌ها

فصل‌ها به سه دلیل مهم هستند. یک فایل طولانی به قطعات ترجمه می‌شود و شکستن فصل‌ها تمیزترین جاهای برش هستند. بعد از ترجمه می‌خواهید هر فصل را بررسی کنید. و اگر بعداً متن را به کتاب الکترونیکی تبدیل کنید، عنوان‌های فصل فهرست مطالب می‌شوند.

هر عنوان را در خط خودش قرار دهید، با یک خط خالی قبل و بعد از آن، و در کل کتاب از یک الگو استفاده کنید. این‌ها الگوهایی هستند که بررسی‌کننده ما می‌شمارد:

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• یک عدد یا یک عدد رومی به تنهایی در یک خط، مانند 12 یا XII.

دستور inspect را اجرا کنید و فهرست عنوان‌هایی را که پیدا کرده بخوانید. اگر کتاب ۴۰ فصل دارد و بررسی‌کننده ۳۷ فصل پیدا می‌کند، سه عنوان پنهان شده‌اند: یکی به اولین جمله چسبیده، یکی از کلمه دیگری مانند «Ch. 7» استفاده کرده، یا یکی متنی در همان خط دارد. آن سه مورد را دستی اصلاح کنید. این کار زمان کمتری از پیدا کردن مشکل در یک فایل ترجمه‌شده می‌برد.

مرحله ۳: شکستن خطوط سخت را با احتیاط بردارید

برخی فایل‌های 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 این را پوشش می‌دهد.

آنچه آزمایش کردیم: متن با شکستن سخت، کامل در برابر تکه‌تکه

می‌خواستیم بدانیم آیا شکستن سخت خطوط واقعاً به ترجمه آسیب می‌زند یا فقط ظاهر نامرتبی دارد. یک داستان کوتاه ۳۹۶ کلمه‌ای برای آزمون نوشتیم: سه فصل، پانزده پاراگراف، دیالوگ، نامهٔ بالا، و یک شکست صحنه با * * *. آن را دو بار با همان کلمات ذخیره کردیم: بدون شکستن خط، با یک پاراگراف در هر خط، و شکسته‌شده در ۶۶ کاراکتر، که ۴۳ خط غیرخالی دارد به‌جای ۱۹ خط.

سپس از یک مدل محلی خواستیم آن را به سه روش به چینی ساده‌شده ترجمه کند، هر روش سه بار:

1. شکسته‌شده، کل فایل. فایل شکسته‌شده در یک درخواست.
2. بدون شکستن، کل فایل. فایل بدون شکستن در یک درخواست.
3. شکسته‌شده، برش هر ۱۲ خط. فایل شکسته‌شده هر ۱۲ خط بریده شد، یک درخواست برای هر تکه، و پاسخ‌ها دوباره به هم متصل شدند. این همان چیزی است که وقتی یک اسکریپت یا ابزار یک فایل طولانی را بر اساس تعداد خط به‌جای پاراگراف تقسیم می‌کند رخ می‌دهد.

مدل Qwen 3.6 27B (Q4_K_M) در LM Studio بود، با تفکر خاموش و دمای ۰.۳، روی Apple M4 Max با ۶۴ گیگابایت حافظه. هر درخواست از همان پرامپت یک‌جمله‌ای استفاده می‌کرد. آن را در ۲۸ اکتبر ۲۰۲۶ اجرا کردیم. اسکریپت run_llm_txt_test.py است، هر نه خروجی بدون ویرایش منتشر شده‌اند، و results.csv یک ردیف برای هر اجرا دارد.

یافتهٔ اول ما را شگفت‌زده کرد. وقتی مدل کل فایلِ سخت‌شکسته را دید، خودش خطوط را به هم چسباند. هر سه خروجی برای هر خط یک پاراگراف داشتند، همان ۱۹ خطِ اجراهای بدون شکست، و به همان خوبی خوانده می‌شدند. پس شکستن سختِ خطوط به‌تنهایی به این مدل در این فایل کوتاه آسیبی نزد.

بریدن فایل بر اساس تعداد خطوط آسیب زد، و هر بار در همان نقاط. سه قطعه از قطعات ۱۲ خطی در میانهٔ جمله تمام می‌شدند. قطعهٔ اول با «He pointed with his» تمام می‌شد و قطعهٔ بعد با «pen at a three-storey building on the corner.» شروع می‌شد. نیمهٔ دوم که جداگانه ترجمه شد، فاعلش را از دست داد. در دو اجرا به‌صورت 她瞥了一眼街角那栋三层楼的建筑، «او نگاهی به ساختمان سه‌طبقهٔ سر خیابان انداخت» بازگشت. در اجرای سوم، با 随后她重新回到填字游戏上، «سپس او به جدول کلمات متقاطع بازگشت» تمام شد. در داستان، مرد داخل باجهٔ بلیت اشاره می‌کند و به جدول کلمات متقاطعش برمی‌گردد. در هر سه اجرا، خوانندهٔ چینی فکر می‌کرد مارا این کار را کرده.

برش دوم، بین «the careful, slightly old-fashioned hand she had learned at a» و «convent school»، جملهٔ چینی را در هر سه اجرا معلق در 那是她在، «آن‌جا بود که او» رها کرد (یک اجرا یک 一 اضافی اضافه کرده بود)، و واژهٔ «learned» ناپدید شد. برش سوم جملهٔ مربوط به کرکره‌ها را به دو خط تقسیم کرد، و نیمهٔ دوم «painted, not well, but not long ago» را به رنگِ کنده تبدیل کرد: 油漆虽已斑驳 در دو اجرا و 油漆剥落 در اجرای سوم. و چون قطعات با یک خط جدید به هم وصل شده بودند، خط خالیِ پیش از شکست صحنه ناپدید شد، و به همین دلیل هر اجرا ۱۴ پاراگراف داشت نه ۱۵. بررسی‌کنندهٔ ما تعداد پاراگراف‌ها را گرفت. نتوانست کاراکتر اشتباه را بگیرد؛ ما آن را با خواندن پیدا کردیم.

این برای فایل شما چه معنایی دارد:

• بازکردنِ خطوط شما را از تقسیم‌کننده‌هایی که کنترلشان را ندارید محافظت می‌کند. هر فایل بلندی جایی تقسیم می‌شود، چه با اسکریپت خودتان، چه با محدودیت پنجرهٔ چت، چه با ابزاری که در آن آپلود می‌کنید. اگر پاراگراف‌ها تک‌خطی و با خطوط خالی از هم جدا شده باشند، هر تقسیم‌کنندهٔ معقولی می‌تواند بین پاراگراف‌ها ببرد نه داخل یک جمله.
• بدترین خطاها روان بودند. «او نگاهی به ساختمان انداخت» چینیِ خوبی است. خواننده شکست‌های عجیب خط در هر برش و 那是她在 معلق را متوجه می‌شود، اما هیچ چیز کاراکتر اشتباه یا رنگ کنده را به‌عنوان خطا علامت نمی‌زند. خطاهای نقاط برش اول خطاهای معنایی‌اند، دوم خطاهای قالب‌بندی.
• این یک مدل و یک داستان کوتاه بود. فایلی به این کوتاهی در یک درخواست جا می‌شود، پس اجراهای کل‌فایل هرگز مجبور به تقسیم چیزی نشدند. یک رمان کامل ناچار باید تقسیم شود، و این دقیقاً همان جایی است که آماده‌سازی در گام‌های ۱ تا ۳ به کار می‌آید. این فایل‌ها آماده‌سازی و تقسیم را می‌آزمایند، نه خط لولهٔ خود BookTranslator را.

یک مشاهدهٔ کوچک‌تر: در شش اجرای کل‌فایل، مدل نام مارا را در پنج اجرا 玛拉 و در یک اجرا 马拉 نوشت. هر خروجی با خودش سازگار بود، اما درخواست‌های جداگانه با هم توافق نداشتند. برای کتابی بلند که در قطعات بسیاری ترجمه می‌شود، فهرستی از نام‌ها و املای توافق‌شدهٔ آن‌ها همهٔ فصل‌ها را هم‌راستا نگه می‌دارد. راهنمای واژه‌نامه ما نشان می‌دهد چگونه یکی بسازید.

گام ۴: ترجمه کنید، سپس شمارش‌ها را بررسی کنید

وقتی فایل تمیز است، ترجمه‌اش بخش آسان است. می‌توانید آن را در مترجم TXT BookTranslator آپلود کنید، که فایل‌های .txt، .md و .mdx را می‌پذیرد، می‌گوید فایل‌های TXT تا ۳۰۰ مگابایت را پشتیبانی می‌کند، و قیمت را پیش از پرداخت نشان می‌دهد. ترجمهٔ کامل رایگان وجود ندارد، اما خود آپلود هزینه را به شما می‌گوید. اگر ترجیح می‌دهید با یک مدل چت یا یک LLM محلی کار کنید، فایل را خودتان در مرزهای فصل یا پاراگراف تقسیم کنید و برای نام‌ها واژه‌نامه نگه دارید. اگر متن شما Markdown است نه نثر ساده، راهنمای ترجمهٔ Markdown ما را ببینید، چون نحو Markdown قواعد خودش را می‌خواهد.

پس از ترجمه، دو فایل را مقایسه کنید:

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

اگر هر یک از فایل‌ها UTF-8 نیست، --source-encoding یا --translated-encoding را اضافه کنید. بررسی فصل الگوهای عنوان انگلیسی و چینی/ژاپنی را می‌شناسد؛ برای زبان‌های مقصد دیگر، واژهٔ محلی «فصل» را به الگوی بالای اسکریپت اضافه کنید.

این گزارش یکی از اجراهای بریده‌شدهٔ ماست:

                            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

این‌طور بخوانیدش:

• پاراگراف‌ها و عنوان‌های فصل باید مطابق باشند. پاراگراف گم‌شده اغلب یعنی دو پاراگراف ادغام شده‌اند یا یکی حذف شده است.
• خطوط غیرخالی می‌توانند به دلیل موجهی متفاوت باشند. اجراهای کل‌فایلِ سخت‌شکستهٔ ما از ۴۳ خط به ۱۹ خط رسیدند چون مدل خطوط سخت‌شکسته را به هم چسباند، که بهبود بود. خطوط را فقط وقتی مقایسه کنید که منبع از قبل بدون شکست بوده است.
• کاراکترهای باقی‌مانده از خط مبدأ به قطعاتی اشاره دارند که اصلاً ترجمه نشده‌اند. چند تا برای نام‌ها، اصطلاحات محصول یا نقل‌قول‌ها طبیعی است؛ یک رشته از آن‌ها یعنی بخشی رد شده است.
• کاراکترهای جایگزین در ترجمه یعنی مشکل کدگذاری در مسیر خروج.

شمارش‌ها نمی‌توانند بگویند ترجمه درست است یا نه. پاراگراف اول و آخر هر فصل را بخوانید، و پاراگراف‌های دو طرف هر جایی که فایل تقسیم شده است. همان‌جاست که آزمون ما هر خطای جدی را پیدا کرد.

پرسش‌های متداول

چرا فایل TXT من در یک برنامه خوب به نظر می‌رسد و در برنامه‌ای دیگر نامفهوم؟

دو برنامه کدگذاری‌های متفاوتی را حدس زده‌اند. یکی درست حدس زده. کدگذاری‌ای را پیدا کنید که متن را درست نشان می‌دهد، سپس فایل را به‌صورت UTF-8 ذخیره کنید تا هر برنامه‌ای یکسان بخواندش.

آیا باید فایل TXT را پیش از ترجمه به EPUB یا DOCX تبدیل کنم؟

فقط اگر می‌خواهید آنچه این قالب‌ها اضافه می‌کنند را داشته باشید. یک فایل TXT تمیز با فصل‌های مشخص، همان‌طور که هست خوب ترجمه می‌شود. اگر فهرست مطالب، پیمایش فصل‌ها و کتاب الکترونیکی قابل خواندن روی دستگاه را می‌خواهید، راهنمای ما برای تبدیل رمان وب به EPUB آماده ترجمه همه را گام‌به‌گام توضیح می‌دهد.

آیا می‌توانم فایل TXT با زبان‌های مختلط را ترجمه کنم؟

بله، اما به مترجم بگویید چه چیزهایی را دست نزند. نقل‌قول‌ها یا اصطلاحات به زبان سوم، و نام‌هایی که باید به خط اصلی خود بمانند، محافظت از آن‌ها با واژه‌نامه یا یک دستور کوتاه آسان‌تر از اصلاح بعدی است.

درباره فایل TXT که از یک وب‌سایت دانلود کرده‌ام چطور؟

بررسی کنید که حق استفاده از آن را دارید. برای کتاب‌های مالکیت عمومی یا فایل‌هایی که خودتان نوشته‌اید، مراحل بالا اعمال می‌شود. رمزگذاری یا قالب یک فایل هیچ چیزی درباره حق تکثیر آن به شما نمی‌گوید.