ترجمه هوش مصنوعی + ایجنت هوش مصنوعی = آسان شدن i18، آیا واقعاً همینطور است؟

هوش مصنوعی در ترجمه: تهدید یا فرصت؟

اتوماتیک‌سازی همیشه در حال تکامل بوده است. ابتدا ماشین‌ها کارهای دستی را ساده کردند؛ سپس کامپیوترها کارهای اداری را دگرگون کردند. برای مترجمان، ابتدا ترجمه ماشینی عصبی سرعت و کیفیت پیش‌نویس اولیه را نسبت به روش‌های قانون‌محور به‌مراتب بهتر کرد. در سال‌های اخیر نیز مدل‌های زبانی بزرگ (LLM) روانی و درک زمینه‌ای را به سطح بالاتری رسانده‌اند.

اما تاریخ همیشه یک نکته را ثابت کرده است:

ماشین‌ها به‌جای حذف یک شغل، ماهیت آن را تغییر می‌دهند.

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

ابزارهای CAT مانند memoQ با ترکیب حافظه‌های ترجمه، گلاسری‌ها، و APIهای ترجمه، آن فرآیند را کارآمد کردند.

اما سؤال اصلی سخنرانی من در Apidays این بود:

آیا نسل بعدی این تکامل، «عامل‌های هوش مصنوعی» هستند؟

آیا می‌توانند پیش‌نویس‌های بهتری بدهند؟

یا حتی بخش‌هایی از جریان‌کار را کاملاً خودکار کنند بدون اینکه کیفیت پایین بیاید؟

منظور از عامل هوش مصنوعی چیست؟

تعاریف مختلفی وجود دارد، اما به‌صورت کاربردی:

عامل هوش مصنوعی = مدل زبانی + کد + ابزارها

مهم‌ترین اجزای چنین عاملی:

• هستهٔ LLM: موتور زبان و استدلال

• ابزارها/APIها: مثل ترجمه، GitHub، فایل‌سیستم…

• حافظه/پایگاه داده: ذخیره وضعیت و داده‌های میانی

• کد هماهنگ‌کننده: مدیریت درخواست‌ها، خطاها، نگهبان‌ها

عامل‌ها بر خلاف یک پاسخ ساده، می‌توانند نتیجه را ارزیابی کنند، سرویس دیگری را فراخوانی کنند و تکرار کنند تا به هدف برسند.

سه کاربرد واقعی عامل‌ها در ترجمه

ما سه سناریو را بررسی کردیم:

• بهبود ترجمه LLM با بازاندیشی و ویرایش چندعاملی
• بین‌المللی‌سازی یک وب‌سایت تک‌زبانه (استخراج رشته‌ها و ساخت JSON منابع)
• خودکارسازی کل گردش‌کار ترجمه تا تحویل نهایی فایل‌ها با نظارت انسان

سناریو ۱ — آیا عامل‌ها واقعاً کیفیت ترجمه را بهتر می‌کنند؟

هدف:
یک LLM ترجمه‌ای انجام داده؛ آیا عامل می‌تواند آن را به‌صورت قابل‌سنجش بهتر کند؟

پاسخ کوتاه:
گاهی بله — اما همیشه نه — و هزینه و زمان مهم‌اند.

رویکردهای رایج:

• بازاندیشی تکراری: ترجمه → نقد خود → اصلاح

• زیرعامل‌های تخصصی: سلیسی، دقت، سبک، ترمینولوژی → ویرایشگر نهایی

• مدل‌های استدلالی: مدل‌های دقیق‌تر برای ترجمه‌های محتاطانه‌تر

نتایج تجربی:

• کیفیت در برخی موارد بهتر می‌شود

• اما هزینه توکنی و تأخیر ممکن است سرسام‌آور شود

• پژوهش‌های دانشگاهی نتایج متفاوت گزارش کرده‌اند

توصیه:

• برای متن‌های کوتاه و بااهمیت (بازاریابی/حقوقی) مناسب است

• قبل از پیچیده‌سازی جریان‌کار، ترجمه ماشینی به‌روز را مقایسه کنید

سناریو ۲ — بین‌المللی‌سازی یک وب‌سایت تک‌زبانه با یک عامل

بسیاری از استارتاپ‌ها با این مشکل مواجه می‌شوند:
اپلیکیشن ساخته شده، رشته‌ها در سراسر کد React به‌صورت hard-coded نوشته شده‌اند، و ناگهان کاربران بین‌المللی ظاهر می‌شوند.

چطور این آشفتگی را به یک سیستم قابل‌محلی‌سازی تبدیل کنیم؟

رویکرد مهندسی استاندارد:

1. اضافه‌کردن یک کتابخانه i18n (مثل i18next)

2. جایگزینی رشته‌های ثابت با کلیدهای معنی‌دار (مانند t('header.welcome'))

3. ساخت فایل‌های JSON منابع برای زبان‌های هدف

4. فراخوانی API ترجمه برای پرکردن محتوای اولیه

5. تست، بازبینی و اصلاح

این کار قابل اسکریپت‌نویسی است… اما چرا عامل‌ها مفیدند؟

• ابزارهای جستجو در کد آن‌ها انعطاف‌پذیرتر از Regex هستند

• نام‌گذاری کلیدها را هوشمندانه و بدون تکرار انجام می‌دهند

• خودکار JSON می‌سازند و ترجمه API را فراخوانی می‌کنند

• حتی pull request ایجاد می‌کنند تا انسان‌ها بازبینی کنند

نیازهای یک عامل موفق برای i18n:

• دسترسی به فایل‌سیستم یا مخزن Git

• دسترسی به API ترجمه

• حافظه برای نگهداری جدول نگاشت کلید ↔ متن اصلی

• ترجیحاً ابزارهای MCP برای کار با Sheetها و ریپو

نمونه جریان‌کار یک عامل:

1. استخراج رشته‌ها از JSX و دیگر فایل‌ها

2. پیشنهاد کلید مناسب و ثبت آن

3. جایگزینی خودکار در کد با تابع ترجمه

4. ساخت فایل‌های JSON برای زبان‌های مختلف

5. بازکردن PR جهت بازبینی انسانی

چرا فقط اسکریپت ننویسیم؟

اسکریپت‌ها:

• سریع و قابل‌اتکا در الگوهای پیش‌بینی‌پذیر
  اما…

• شکننده‌اند در پروژه‌های آشفته و ساختارهای غیرمعمول

عامل‌ها:

• می‌توانند حدس بزنند، سؤال بپرسند، جستجو کنند
  به‌خصوص در مهاجرت‌های سریع بسیار ارزشمندند

اما:

انسان باید در حلقه بماند

• تشخیص اینکه کدام رشته باید ترجمه شود

• بررسی دقیق کلیدها

• بازبینی کیفیت ترجمه و مطابقت با UI

سناریو ۳ — خودکارسازی کامل جریان‌کار ترجمه

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

جریان‌کار نمونه:

1. استخراج رشته‌ها و ترجمه اولیه ماشینی

2. ثبت ترجمه‌ها در یک Sheet مشترک

3. ویرایش و تأیید توسط مترجمان

4. خروجی گرفتن فایل‌های JSON نهایی و بازگشت به ریپو

چرا Sheet؟

• نقطه مرجع تأیید انسانی برای بسیاری از تیم‌هاست

• امکان مشاهده متن، افزودن توضیحات و همکاری

• ابزار آشنا برای افراد غیر فنی

الگوهای ضروری:

• ایمن‌بودن تکرار (اجرا دوباره بدون خرابی)

• ثبت تاریخچه (چه کسی چه چیزی را اصلاح کرد)

• محدودیت دسترسی (تعهد مستقیم به main ممنوع!)

• اعتبارسنجی (طول متن، نگهداری Placeholderها)

• پرچم‌گذاری ابهام‌ها برای انسان، نه حدس‌زدن

عامل‌ها در کارهای تکراری عالی‌اند اما تصمیم‌گیری‌های ظریف همچنان انسانی است

دام‌ها و خطاهای رایج — و راه‌حل‌ها

۱. هزینه توکن و تأخیر بالا

• ابتدا روی نمونه کوچک بسنجید

• از مدل مناسب برای ترجمه انبوه استفاده کنید

۲. اتوماسیون بیش‌ازحد بدون کنترل

• حتماً از شاخه و PR استفاده کنید

• گام‌های قابل لغو و قابل بازبینی طراحی کنید

۳. از دست دادن بافت و زمینه

• ترجمه بدون UI → احتمال اشتباه

• اطلاعات تکمیلی کوتاه اضافه کنید

۴. تشخیص اشتباه رشته‌ها

• ترکیب عامل + بررسی انسانی

• مرحله تأیید رشته‌های استخراج‌شده

۵. بی‌ثباتی Sheet

• جستجو بر اساس عنوان ستون، نه شماره ستون

• MCPها کمک می‌کنند

چه زمانی عامل‌ها؟ چه زمانی کدنویسی؟

شرایط	بهترین انتخاب
مقیاس بالا، الگوهای مشخص	اسکریپت و CI
پروژه پیچیده، رشته‌ها پراکنده	عامل‌های هوش مصنوعی
بهترین حالت	ترکیب هر دو — اکتشاف عامل + اتوماسیون پایدار

چک‌لیست عملی قبل از استقرار عامل‌های i18n

• شناسایی محل رشته‌ها: فایل‌ها و نقاطی که متن UI در آن قرار دارد

• انتخاب استراتژی i18n: کتابخانه، الگوی نام‌گذاری کلیدها

• سطح دسترسی امن: شاخه مجزا، قوانین تأیید PR

• آماده‌سازی ابزارها: دسترسی API ترجمه، Sheet یا MCP

• اجرای آزمایشی عامل روی یک بخش کوچک

• بازبینی توسط مترجمان و مهندسان

• نهایی‌سازی خودکار: ایجاد فایل منابع و ارسال PR انتشار

• کنترل کیفیت نهایی در UI: طول متن، Placeholderها، سوئیچ زبان

امنیت و انطباق

وقتی عامل به کد و متن دسترسی دارد، باید مراقب بود:

• اطلاعات حساس یا محرمانه به سرویس‌های خارجی ارسال نشود

• در صورت حساس‌بودن داده‌ها، مدل‌ها در محیط خصوصی اجرا شوند

• کلیدهای دسترسی به‌صورت محدود تعریف و مرتباً چرخش یابند

• مسیرهای انتقال داده کاملاً قابل پیگیری و حسابرسی باشند

آینده این فناوری به کدام سمت می‌رود؟

انتظار پیشرفت سریع در حوزه‌های زیر:

• کارایی هزینه‌ای: مدل‌های سبک‌تر، ارکستراسیون هوشمندتر

• اتصال‌پذیری پیشرفته: MCPهای بهتر برای Sheets، ریپو و ذخیره‌سازی

• درک زمینه‌ای قوی‌تر: بهره‌گیری از اسکرین‌شات‌ها و متاداده‌های UI

• تخصص‌گرایی: عامل‌های آموزش‌دیده برای صنایع خاص با ترمینولوژی پایدار

برای مترجمان و تیم‌های محلی‌سازی:

عامل‌ها تهدید نیستند — فرصت هستند تا کارهای تکراری به ماشین سپرده شود و تمرکز انسان بر خلاقیت، ظرافت و تصمیم‌گیری بماند

نتیجه‌گیری — عامل‌ها، همکاران پرانرژی نه جایگزین متخصصان

عامل‌ها به «کارآموزی بسیار مشتاق که هرگز خسته نمی‌شود» تشبیه می‌شوند:

• رشته‌ها را پیدا می‌کند

• کلیدها را پیشنهاد می‌دهد

• ترجمه ماشینی تهیه می‌کند

• فایل‌های منابع ایجاد می‌کند

اما:

• گاهی اشتباه می‌کند
• گاهی زیاده‌روی می‌کند
• همیشه نیاز به هدایت دارد

پس باید:

• از عامل‌ها برای سرعت‌بخشیدن و اکتشاف استفاده کرد

• اما قفل کیفیت و مالکیت همچنان در دست انسان بماند

بهترین ترکیب:

انعطاف‌پذیری عامل + اتوماسیون پایدار

نتیجه:

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

اگر می‌خواهید همین ایده‌ها را در عمل تست کنید:

• یک کامپوننت کوچک React انتخاب کنید
• عامل ساده‌ای بنویسید برای استخراج رشته‌ها و تولید JSON فرانسوی
• نتیجه را با مترجم انسانی مرور کنید
• تکرار کنید

خیلی زود می‌بینید این روش:

• چقدر وقت ذخیره می‌کند

• و کجا هنوز به قضاوت انسانی نیاز دارد