مقدمه

ترجمه خودکار از آزمایشگاه‌های تجربی به فرایندهای روزمره کسب‌وکار منتقل شده است. با این حال رایج‌ترین مانع، خود موتور ترجمه نیست، بلکه شکل مطالب منبع است. اسناد، جدول‌های صفحه‌گسترده، ارائه‌ها و دارایی‌های چندرسانه‌ای در قالب‌های مالکیتی گوناگون ظاهر می‌شوند، هر کدام با نکات خاص خود دربارهٔ قلم‌ها، اشیاء جاسازی‌شده و فراداده‌ها. هنگامی که یک خط لوله ترجمه فایلی را دریافت می‌کند که نتواند به‌صورت تمیز آن را تجزیه کند، موتور یا شکست می‌خورد یا خروجی‌ای پر از خطاهای قالب‌بندی، لینک‌های شکسته یا از دست رفتن زمینه تولید می‌کند. راه‌حل، مرحلهٔ تبدیل فایل منظم است که ورودی‌ها را به فرمت سازگار با ترجمه نرمال‌سازی می‌کند، متن را از طریق مدل ترجمهٔ ماشینی می‌برد و سپس طرح اصلی را برای بازبینی نهایی بازساخت می‌کند. این مقاله جریان کار انتها‑به‑انتها را مرور می‌کند، توضیح می‌دهد چرا برخی فرمت‌های واسط ترجیح‌دارند و چک‌های عملی برای نگه داشتن کیفیت، امنیت و سازگاری برند ارائه می‌دهد.

انتخاب فرمت میانی برای ترجمه

اکثر موتورهای ترجمه بر متون ساده، XLIFF (فرمت تبادل بومی‌سازی XML) یا HTML کار می‌کنند. انتخاب فرمت میانی مناسب به سه عامل بستگی دارد: صداقت ساختاری، حفظ فراداده و پیچیدگی بازترکیب در مرحلهٔ بعدی.

• متن ساده تمام نشانه‌های تصویری را حذف می‌کند. این ایمن‌ترین گزینه برای محتوای صرفاً زبانی است (مثلاً فایل‌های زیرنویس) اما جداول، پاورنوت‌ها و اطلاعات سبک را از بین می‌برد.
• XLIFF به‌طور خاص برای بومی‌سازی ساخته شده است. این فرمت رشته‌های منبع، نکات متنی و محل‌گیرهای برچسب‌های قالب‌بندی را ذخیره می‌کند. وقتی سند منبع شامل طرح‌های پیچیده باشد — بروشورهای چندستونی، نمودارهای جاسازی‌شده یا پاورنوت‌ها — XLIFF می‌تواند محل‌گیرهایی نگه دارد که بعدها به طرح اصلی بازمی‌گردند.
• HTML برای محتوای وب‌محور و اسنادی که قبلاً شامل استایل‌های CSS هستند، مناسب است. APIهای ترجمهٔ مدرن می‌توانند HTML را دریافت کنند در حالی که برچسب‌های سطح‌بلوک را حفظ می‌کنند، که این کار گام بازترکیب را به یک عملیات سادهٔ جای‌گزینی تبدیل می‌کند.

برای اکثر اسناد تجاری (قراردادها، راهنمای محصولات، بروشورهای بازاریابی) تبدیل دو‑مرحله‌ای — ابتدا به XLIFF برای موتور ترجمه و سپس بازگشت به فرمت اصلی — بهترین تعادل بین دقت و خودکارسازی را فراهم می‌کند. هنگام کار با داده‌های صفحه‌گسترده، تبدیل CSV به XLIFF با لایهٔ نقشه‌برداری سفارشی، مختصات سلول‌ها و فرمول‌ها را حفظ می‌کند.

آماده‌سازی فایل‌های منبع: پاک‌سازی، نرمال‌سازی و ایمن‌سازی

قبل از اینکه فایلی به موتور ترجمه برسد، مرحلهٔ پیش‌پردازش باید سه دستهٔ ریسک را برطرف کند: نویز, کدگذاری ناسازگار و نمایش داده‌های حساس.

حذف نویز

اسناد ارثی اغلب شامل اشیاء مخفی (نشانه‌های آب، علامت‌های تجدیدنظر، تغییرات ردیابی‌شده) هستند که ابزارهای تبدیل را گیج می‌کنند. یک رویکرد عملی عبارت است از:

1. منبع را در ویرایشگر بومی خود باز کنید.
2. تمام تغییرات ردیابی‌شده را بپذیرید یا رد کنید و نظرات را حذف کنید.
3. لایه‌ها را در تصاویر مسطح کنید و عناصر برداری که برای ترجمه لازم نیستند را به رستر تبدیل کنید.
4. یک نسخهٔ پاک از فایل را صادر کنید و پرچم فقط‑خواندنی را برای جلوگیری از ویرایش‌های تصادفی حفظ کنید.

نرمال‌سازی کدگذاری

فایل‌های متنی ممکن است در UTF‑8، UTF‑16، ISO‑8859‑1 یا کدگذاری‌های قدیمی دیگر ذخیره شوند. تشخیص نادرست منجر به کاراکترهای خراب پس از تبدیل می‌شود. از ابزاری استفاده کنید که بتواند UTF‑8 را شناسایی و اعمال کند پیش از اولین گام تبدیل. به عنوان مثال، یک اسکریپت کوچک می‌تواند بر روی هر payload .txt یا .csv iconv را فراخوانی کند و در صورت شکست تبدیل به بازبینی دستی بازگردد.

مدیریت داده‌های حساس

سرویس‌های ترجمهٔ خودکار بر روی سرورهای راه‌دور اجرا می‌شوند؛ هر گونه اطلاعات شناسایی شخصی (PII) که در منبع باقی بماند باید مخفی شود. یک چک‌لیست عملی شامل:

• اجرای اسکن مبتنی بر regex برای آدرس‌های ایمیل، شماره‌های تلفن و الگوهای کارت‌های اعتباری.
• حذف یا محو کردن فراداده‌های جاسازی‌شده (نویسنده، نام شرکت) با استفاده از ابزار حذف فراداده.
• نگهداری یک فایل نقشهٔ امن که مقادیر اصلی و محل‌گیرهایشان را ثبت می‌کند تا در صورت نیاز پس از ترجمه دوباره جایگزین شوند.

تبدیل به فرمت آماده‌برای‑ترجمه

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

جریان کار گام‑به‑گام

1. فایل منبع را بارگذاری کنید به نقطهٔ انتهایی تبدیل، خروجی XLIFF را درخواست کنید. اکثر APIها به شما اجازه می‌دهند طرح هدف (مثلاً xliff-1.2 یا xliff-2.0) را مشخص کنید.
2. XLIFF را اعتبارسنجی کنید – اطمینان حاصل کنید که هر عنصر <source> شامل رشته‌ای غیر خالی باشد و محل‌گیرها (<ph>) به‌درستی به برچسب‌های قالب‌بندی اصلی نگاشته شده باشند.
3. موتور ترجمه را اجرا کنید – XLIFF را به سرویس ترجمهٔ ماشینی بدهید، در صورت نیاز واژه‌نامه‌ای فعال کنید که اصطلاحات خاص برند را تحمیل کند.
4. XLIFF ترجمه‌شده را پس‌پردازش کنید – یک اسکریپت بررسی کیفیت اجرا کنید که رشته‌های بیش از حد طولانی، محل‌گیرهای مفقود یا بخش‌های ترجمه‌نشده را علامت بزند.

اگر منبع یک ارائه باشد، گزینهٔ جایگزین این است که ابتدا PowerPoint (.pptx) را به HTML تبدیل کنید، زیرا HTML عناوین اسلاید، یادداشت‌های سخنران و متن Alt‑تصاویر را حفظ می‌کند. پس از ترجمه، HTML می‌تواند با یک موتور قالب‌سازی به PowerPoint جدید بازسازی شود که متن ترجمه‌شده را به محل‌گیرهای اسلاید بازمی‌گرداند.

بازترکیب محتوای ترجمه‌شده

خطا‑پذیرترین مرحله، دوختن رشته‌های ترجمه‌شده به طرح اصلی است. کلید کار داشتن جدول نگاشت است که رابطهٔ هر محل‌گیر با محتوی‌ساز مربوطه در فایل منبع را ثبت می‌کند.

استفاده از محل‌گیرهای XLIFF

برچسب‌های <ph> در XLIFF شامل یک ویژگی id هستند. هنگام تبدیل سند اصلی، مبدل این شناسه‌ها را به عنوان مارکرهای نامرئی (مثلاً فضای‌نام XML سفارشی یا spanهای پنهان) وارد می‌کند. پس از ترجمه، یک پس‌پردازش XLIFF ترجمه‌شده را می‌خواند، هر عنصر <target> را پیدا می‌کند و مارکر متناظر در سند منبع را جایگزین می‌نماید.

مدیریت عناصر غیر‑متنی

تصاویر، نمودارها و ویدیوهای جاسازی‌شده نباید به موتور ترجمه فرستاده شوند. در عوض آنها را به‌عنوان دارایی‌های ثابت حفظ کنید و از طریق محل‌گیرها به آنها ارجاع دهید. هنگام بازترکیب، اسکریپت به سادگی داده‌های باینری اصلی را به مکان مناسب بازمی‌گرداند. برای PDFها، ابزارهایی مانند pdf-lib می‌توانند اشیاء متنی را جایگزین کنند در حالی که جریان صفحات بدون تغییر می‌ماند و گرافیک‌های برداری حفظ می‌شوند.

تأیید نهایی کیفیت

یک گام تأیید کامل ریسک قالب‌های خراب را کاهش می‌دهد:

• سند بازترکیب‌شده را در نمایشگر بومی‌اش (Word، Acrobat، PowerPoint) رندر کنید و تفاوت‌های بصری را با اصل با یک ابزار مقایسه پیکسل‌به‑پیکسل مقایسه کنید.
• یک بررسی خودکار املایی بر زبان ترجمه‌شده اجرا کنید تا هرگونه محل‌گیر ترجمه‌نشده را بگیرد.
• اطمینان حاصل کنید تمام قلم‌های جاسازی‌شده هنوز جاسازی هستند؛ قلم‌های گمشده می‌توانند هنگام باز شدن فایل در رایانهٔ دیگر باعث جابجایی طرح شوند.

بهترین شیوه‌های خودکارسازی برای پروژه‌های بزرگ‌مقیاس

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

سرویس‌های تبدیل مبتنی بر کانتینر

کامپوننت تبدیل را به شکل یک کانتینر Docker استقرار دهید که همان نسخهٔ موتور تبدیل (مثلاً یک نمونهٔ سر‌سخت LibreOffice یا API ابر) را اجرا می‌کند. این تضمین می‌کند یک .docx تولید‑شده امروز، ماه آینده به‌طور یکسان رندر می‌شود و «پایین‌رفتار فرمت» از بین می‌رود.

پردازش همسان (Idempotent)

هر گام را طوری طراحی کنید که بدون اثرات جانبی قابل تکرار باشد. اگر یک اجرا ترجمه در میانه مسیر شکست بخورد، اجرای دوباره باید دقیقاً از همان نقطه ادامه یابد، با استفاده از همان جداول نگاشت و بدون تولید محل‌گیرهای تکراری. فایل‌های XLIFF واسطی را در یک سطل نسخه‑کنترل‌شده با زمان‑مهر واضح ذخیره کنید.

لاگ‌گیری و ردپای حسابرسی

اگرچه جریان کار تا مرحلهٔ QA نهایی از بازبینی انسانی دور است، محیط‌های نظارتی (مثلاً مستندات دستگاه‌های پزشکی) نیاز به یک لاگ کامل دارند. هش هر فایل منبع، هش هر XLIFF واسط و هش آثار ترجمه‌شده نهایی را ثبت کنید. این زنجیرهٔ رمزنگاری‌شده می‌تواند بعدها مورد تأیید قرار گیرد.

همزمانی و محدودیت نرخ

اکثر APIهای ترجمهٔ ابری محدودیت نرخ دارند. درخواست‌های تبدیل را بچ کنید، اما تماس‌های ترجمه را طوری محدود کنید که در حدود سهمیه بمانید و در عین حال کارگرهای تبدیل مشغول بمانند. یک سیستم صف ساده (مثلاً RabbitMQ) می‌تواند جریان را هماهنگ کند: کارگرها پیام «آماده برای ترجمه» را می‌کشند، XLIFF را پردازش می‌کنند و پیام «آماده برای بازترکیب» را فشار می‌دهند.

ملاحظات امنیتی خاص به لوله‌های ترجمه

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

• رمزنگاری سرتاسری – قبل از بارگذاری فایل منبع را رمزنگاری کنید، رمزنگاری‌متن را از طریق TLS منتقل کنید و فقط داخل کانتینر تبدیل مورد اعتماد رمزگشایی کنید.
• پردازش بدون دانش (Zero‑knowledge) – سرویسی را انتخاب کنید که پس از تراکنش فایل را ذخیره نکند. معماری Convertise.app فایل‌ها را در حافظه پردازش می‌کند و بلافاصله پس از پاسخ حذف می‌نماید، که با مدل صفر‑دانش هم‌خوانی دارد.
• ساکنان داده – اگر قوانین نیاز دارند داده‌ها در یک منطقه جغرافیایی خاص بمانند، کانتینر تبدیل را در آن منطقه سازگار مستقر کنید و درخواست‌های ترجمه را به تأمین‌کننده‌ای هدایت کنید که نقطهٔ انتهای منطقه‑خاص ارائه می‌دهد.
• کنترل دسترسی – جداول نگاشت و طرح‌های محل‌گیر را در یک مخزن مدیریت راز (مثلاً HashiCorp Vault) ذخیره کنید و فقط به سرویس‌های خط لوله‌ای که به آنها نیاز دارند مجوز خواندن/نوشتن بدهید.

نتیجه‌گیری

ترجمه خودکار تنها به اندازه ساختار تبدیل فایل که آن را تغذیه می‌کند خوب است. با نرمال‌سازی فایل‌های منبع به فرمت آماده‌برای‑ترجمه، پاک‌سازی دقیق محتوا، حفظ مکان‌گیرهای ساختاری و بازسازی نهایی اثر با یک فرایند تعین‌پذیر و حسابرسی‑پذیر، سازمان‌ها می‌توانند زمان تحویل سریع داشته باشند بدون اینکه یکپارچگی طرح، سازگاری برند یا حریم‌خصوصی داده‌ها به خطر بیفتد. جریان کاری که در اینجا شرح داده شد می‌تواند با ابزارهای متن‑باز، سرویس‌های کانتینریزه و مبدل ابر‑محور با تمرکز بر حریم‌خصوصی مانند convertise.app پیاده‌سازی شود، به تیم‌ها امکان می‌دهد پروژه‌های بومی‌سازی را از چند صفحه تا کتابخانهٔ سازمانی دارایی‌های چندزبانه گسترش دهند.