PolyLingo در مقابل DeepL API: کدام یک JSON و Markdown را بهتر حفظ می‌کند؟

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

سوالی که این پست به آن پاسخ می‌دهد، محدودتر است: وقتی محتوای شما ساختار دارد، API DeepL چگونه عمل می‌کند؟ وقتی نیاز دارید یک فایل locale JSON را بدون دست زدن به کلیدها ترجمه کنید، یا یک پست بلاگ Markdown را بدون شکستن نحو آن، یا یک صفحه HTML را بدون خراب کردن ویژگی‌ها؟ و در این مورد خاص، چگونه با PolyLingo مقایسه می‌شود؟

ساختار API DeepL چگونه است

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

DeepL از ترجمه اسناد برای فرمت‌هایی مانند PDF، Word، PowerPoint و HTML نیز پشتیبانی می‌کند، اما این از طریق یک نقطه پایانی سند جداگانه با جریان متفاوت انجام می‌شود: فایل را آپلود می‌کنید، منتظر اتمام می‌مانید، نتیجه را دانلود می‌کنید. این برای اسناد اداری طراحی شده است، نه برای خطوط پردازش محتوای برنامه‌ریزی شده.

برای HTML به طور خاص، پارامتری به نام tag_handling وجود دارد که می‌توانید آن را روی html تنظیم کنید، که به DeepL می‌گوید ورودی را به عنوان HTML در نظر بگیرد و سعی کند تگ‌ها را حفظ کند. این برای نشانه‌گذاری ساده به خوبی کار می‌کند، اما یک گزینه اختیاری است که باید بدانید چگونه تنظیم شود و به JSON یا Markdown تعمیم نمی‌یابد.

برای JSON پشتیبانی بومی وجود ندارد. نقطه پایانی متن DeepL نمی‌داند کلید JSON چیست. اگر یک شیء JSON سریال‌شده به آن ارسال کنید، محتوا را به عنوان رشته ترجمه می‌کند و هیچ تضمینی وجود ندارد که کلیدها، ساختار یا مقادیر غیررشته‌ای سالم بمانند. کتابخانه R به نام babeldown که DeepL را برای محتوای Markdown بسته‌بندی می‌کند، مواردی را مستند کرده که DeepL علائم نگارشی داخل لینک‌ها و قالب‌بندی Markdown را اشتباه می‌گیرد، که محدودیت شناخته‌شده‌ای است هنگام عبور متن ساختاریافته از یک موتور ترجمه متن ساده.

این انتقادی به DeepL نیست. این توصیفی است از آنچه API برای انجام آن طراحی شده است. مورد استفاده اصلی DeepL ترجمه با کیفیت بالا از نثر قابل خواندن توسط انسان است. این چیزی است که برای آن بهینه شده و در آن عالی است.

تفاوت در عمل کجا دیده می‌شود

تفاوت زمانی آشکار می‌شود که محتوای شما دیگر نثر ساده نباشد.

یک فایل locale استاندارد Next.js را در نظر بگیرید:

{
  "nav": {
    "home": "خانه",
    "about": "درباره ما",
    "contact": "تماس"
  },
  "hero": {
    "title": "به پلتفرم ما خوش آمدید",
    "subtitle": "همه چیزهایی که نیاز دارید در یک مکان"
  }
}

برای ترجمه این با API DeepL به پنج زبان باید:

هر مقدار رشته‌ای را جداگانه استخراج کنید
برای هر زبان یک درخواست API جداگانه ارسال کنید (پنج زبان، پنج درخواست)
ساختار JSON را با مقادیر ترجمه شده در مکان‌های درست بازسازی کنید
هر موردی که ترجمه علائم نگارشی را تغییر داده یا کاراکترهایی وارد کرده که اعتبار JSON را می‌شکند، مدیریت کنید

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

با PolyLingo شما شیء را همان‌طور که هست با format: "json" ارسال می‌کنید و نسخه ترجمه شده کل ساختار را برای هر زبان مقصد در یک پاسخ دریافت می‌کنید. کلیدها دست نخورده باقی می‌مانند. تو در تو بودن حفظ می‌شود. مقادیر غیررشته‌ای دست نخورده می‌مانند. خروجی مستقیماً وارد پروژه شما می‌شود.

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "{\"nav\":{\"home\":\"خانه\",\"about\":\"درباره ما\"}}",
    "format": "json",
    "targets": ["fr", "de", "es", "ja", "nl"]
  }'

یک درخواست. پنج زبان. ساختار سالم.

محتوای Markdown

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

پرچم فرمت markdown در PolyLingo به مدل دستور می‌دهد که نحو Markdown را ساختاری و نه قابل ترجمه در نظر بگیرد. عناوین به عنوان عناوین باقی می‌مانند. بلوک‌های کد محصور شده به صورت دقیق حفظ می‌شوند. URLهای لینک تغییر نمی‌کنند. فقط محتوای نثر تغییر می‌کند.

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

تفاوت یک درخواست در مقابل یک درخواست برای هر زبان

ارزش دارد که روی این موضوع تأمل کنیم چون پیامدهای هزینه واقعی است.

API DeepL فقط یک زبان مقصد را در هر درخواست می‌پذیرد. برای ترجمه یک قطعه محتوا به ده زبان، ده تماس API انجام می‌دهید. برای یک سایت بزرگ یا CMS با انتشار مکرر، این ده برابر سربار درخواست، ده برابر تأخیر برای مدیریت و ده برابر نقاط شکست است.

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

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

مدل قیمت‌گذاری

DeepL بر اساس تعداد کاراکتر هزینه می‌گیرد. طرح رایگان API اجازه می‌دهد تا ۵۰۰,۰۰۰ کاراکتر در ماه، و طرح‌های پولی بر اساس مصرف کاراکتر صورتحساب می‌کنند. چون برای هر زبان یک درخواست می‌فرستید، تعداد کاراکترهای یک محتوا در تعداد زبان‌های مقصدی که به آنها ارسال می‌کنید ضرب می‌شود، چون درخواست‌ها جداگانه هستند.

PolyLingo بر اساس توکن هزینه می‌گیرد و مجموع ورودی و خروجی برای همه زبان‌ها را در یک درخواست می‌شمارد. صورتحساب شفاف و قابل پیش‌بینی است: سطح رایگان شامل ۵۰,۰۰۰ توکن در ماه است، با طرح‌های پولی که از ۹ دلار در ماه برای ۶۰۰,۰۰۰ توکن شروع می‌شوند.

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

هر کدام کجا مناسب است

API DeepL انتخاب درست است وقتی:

محتوای شما نثر ساده بدون نیازهای ساختاری است
کیفیت ترجمه برای متن قابل خواندن توسط انسان اولویت اصلی است
در حال ترجمه به تعداد کمی زبان هستید و حجم درخواست‌ها کم است
قبلاً در اکوسیستم DeepL سرمایه‌گذاری کرده‌اید و از فرهنگ لغت یا ویژگی‌های رسمیت آنها استفاده می‌کنید
نیاز به پشتیبانی از زبانی خارج از ۳۶ زبان فعلی PolyLingo دارید (DeepL بیش از ۱۰۰ زبان را پشتیبانی می‌کند)

PolyLingo انتخاب درست است وقتی:

محتوای شما JSON، Markdown یا HTML است و ساختار باید حفظ شود
نیاز دارید به چندین زبان در یک تماس API ترجمه کنید
در حال ساخت یک ادغام CMS یا خط لوله i18n هستید که کارایی درخواست‌ها مهم است
می‌خواهید یک رابط کاربری یکنواخت در همه فرمت‌های محتوا بدون راه‌حل‌های خاص فرمت داشته باشید
می‌خواهید صورتحساب مبتنی بر توکن با سهمیه ماهانه قابل پیش‌بینی داشته باشید

خلاصه کنار هم

	PolyLingo	DeepL API
پشتیبانی بومی JSON	بله	خیر
پشتیبانی بومی Markdown	بله	خیر
پشتیبانی HTML	بله	بله (پرچم tag_handling)
همه زبان‌ها در یک درخواست	بله	خیر، یک زبان در هر درخواست
تشخیص خودکار فرمت محتوا	بله	خیر
زبان‌های پشتیبانی شده	۳۶	بیش از ۱۰۰
سطح رایگان	۵۰,۰۰۰ توکن/ماه	۵۰۰,۰۰۰ کاراکتر/ماه
واحد صورتحساب	توکن	کاراکتر
مترجم وب بدون کد	بله	بله (اپ وب)

DeepL فهرست زبان‌های بزرگ‌تر و سابقه طولانی‌تری در کیفیت ترجمه نثر دارد. PolyLingo به طور خاص برای جریان‌های کاری محتوای ساختاریافته ساخته شده است که یکپارچگی فرمت غیرقابل مذاکره است.

آنها مشکلات مجاور را حل می‌کنند. انتخاب درست بستگی به این دارد که محتوای شما واقعاً چگونه است.

امتحان PolyLingo

سطح رایگان شامل ۵۰,۰۰۰ توکن در ماه است. کارت اعتباری لازم نیست. مستندات کامل API در usepolylingo.com/docs موجود است.

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# سلام\n\nاین یک محتوای **ساختاریافته** است.",
    "format": "markdown",
    "targets": ["fr", "de", "es"]
  }'

کلید API خود را دریافت کنید