چگونه دامنه یکپارچه‌سازی ترجمه را برای یک اپلیکیشن کسب‌وکار موجود تعریف کنیم
ترجمه را در اپلیکیشن کسب‌وکار خود برنامه‌ریزی کنید. پیش از درخواست پیشنهاد قیمت، محتوا، زبان‌ها، بازبینی، قواعد داده، مدیریت خطا و آزمون‌های پذیرش را تعریف کنید.
با یک کار کامل شروع کنید که تیم شما باید به زبانی دیگر انجام دهد. سپس تعریف کنید ترجمه چگونه در آن کار جای می‌گیرد. این کار، در مقایسه با درخواستِ صرفِ افزودن یک دکمه ترجمه، مبنای روشن‌تری برای برآورد در اختیار تأمین‌کننده نرم‌افزار می‌گذارد.
دامنه باید متن، افراد، داده و نتیجه را پوشش دهد. همچنین باید توضیح دهد وقتی ترجمه ناموفق است چه اتفاقی می‌افتد. پیش از انتخاب رویکرد فنی، با مراحل زیر این دامنه را آماده کنید.
یک گردش‌کار برای نخستین نسخه انتخاب کنید
بنویسید متن مبدأ از کجا می‌آید و ترجمه تأییدشده باید به کجا برود. برای مثال، ممکن است یک کارمند پشتیبانی لازم داشته باشد پیام دریافتی را بخواند و پاسخی به زبان مشتری آماده کند. این یک نیازمندی فرضی است، نه گزارشی از یک نصب Vavus.
هر مرحله را فهرست کنید: باز کردن پیام، درخواست ترجمه، خواندن متن مبدأ در کنار نتیجه، ویرایش پاسخ و تأیید آن برای ارسال. تصمیم بگیرید که ترجمه خودکار آغاز شود یا فقط پس از آنکه کارمند آن را انتخاب کرد.
نخستین نسخه را کوچک نگه دارید. آزمایش یک صفحه و یک کار تجاری روشن آسان‌تر از آزمایش همه فیلدهای متنی یک اپلیکیشن است.
نیازهای محتوایی و زبانی را مشخص کنید
فهرستی از فیلدهایی که به ترجمه نیاز دارند تهیه کنید. برچسب‌های کوتاه، متن آزاد، اسناد و گفتار را از هم جدا کنید. این‌ها ممکن است به پردازش و آزمون‌های متفاوتی نیاز داشته باشند. فیلدهایی را هم که باید بدون تغییر بمانند، مانند شماره سفارش و کد محصول، فهرست کنید.
زبان‌های مبدأ و مقصد را، از جمله گونه‌های منطقه‌ای، مشخص کنید. طول معمول متن و حجم روزانه مورد انتظار را ثبت کنید. بپرسید سرویس پیشنهادی از کدام ترکیب‌های زبانی و قالب‌های ورودی پشتیبانی می‌کند.
در متن‌های کوتاه، بافت می‌تواند اهمیت داشته باشد. برای مثال، API متن DeepL از پارامتر context پشتیبانی می‌کند که می‌تواند بر ترجمه اثر بگذارد بی‌آنکه خود این بافت ترجمه شود. مستندات آن همچنین می‌گوید ورودی‌های متنی جداگانه در یک درخواست، بافت مشترکی ندارند. [1] دامنه شما باید مشخص کند بافت مفید از کجا می‌آید.
اصطلاحات و بازبینی انسانی را تعریف کنید
اصطلاحاتی را که کسب‌وکار شما زیاد به کار می‌برد گردآوری کنید. ترجمه‌های ترجیحی، نام محصولات و واژه‌هایی را که باید بدون تغییر بمانند بگنجانید. یک نفر را مسئول نگهداری این فهرست کنید.
برخی سرویس‌های ترجمه از واژه‌نامه پشتیبانی می‌کنند. Google Cloud Translation واژه‌نامه خود را فرهنگ لغتی سفارشی برای یکدست ماندن اصطلاحات تخصصی یک حوزه توصیف می‌کند. [2] این قابلیت را برای جفت‌های زبانی دقیق و سرویس انتخابی خود بررسی کنید. واژه‌نامه ثابت نمی‌کند که کل پیام درست است.
تصمیم بگیرید کدام خروجی‌ها به بازبین زبانی واجد صلاحیت نیاز دارند. به بازبین دسترسی به متن اصلی بدهید. پیش از ارسال یا انتشار متنی که مشتری می‌بیند، یک مرحله تأیید روشن تعیین کنید.
قواعد داده و دسترسی را تعیین کنید
توضیح دهید گردش‌کار با چه اطلاعاتی سروکار دارد. در آزمون‌های اولیه از نمونه‌های ساختگی استفاده کنید. از کپی کردن سوابق واقعی مشتریان در یک آزمایش، فقط برای دیدن اینکه یک دکمه کار می‌کند یا نه، خودداری کنید.
بپرسید متن کجا پردازش می‌شود، اپلیکیشن چه چیزی ذخیره می‌کند، چه کسی می‌تواند آن را بخواند و چه زمانی حذف می‌شود. گزارش‌های فنی و نسخه‌های پشتیبان را هم در این گفتگو بگنجانید. شرایط فعلی ارائه‌دهنده و کنترل‌های موجود برای پلن انتخاب‌شده را تأیید کنید.
یک رابط سفارشی به‌خودی‌خود یک سرویس ترجمه بیرونی را خصوصی یا آفلاین نمی‌کند. اگر پروژه شما به پردازش محلی نیاز دارد، این نیاز را از ابتدا اعلام کنید و کل جریان داده را با آن بسنجید.
برای تأخیرها و خطاها برنامه‌ریزی کنید
زمان پاسخ مورد انتظار و اقدامی را که کارکنان باید در صورت در دسترس نبودن سرویس انجام دهند بنویسید. اپلیکیشن باید وضعیت روشنی نشان دهد، مانند در انتظار، آماده بازبینی یا ناموفق. متن اصلی را حفظ کنید.
از توسعه‌دهنده بخواهید خطاهای موقت را از خطاهایی که به تغییر نیاز دارند تفکیک کند. برای مثال، DeepL برای خطاهای محدودیت نرخ، تلاش مجدد با تأخیر را مستند کرده است، در حالی که تمام شدن سهمیه واکنش دیگری می‌طلبد. [3] درخواست‌های تکراری نباید اقدامات تجاری تکراری ایجاد کنند، مانند دو بار ارسال یک پاسخ.
درباره هشدارهای مصرف و اینکه پشتیبانی بر عهده چه کسی است توافق کنید. هنگام مقایسه هزینه‌های پروژه، هزینه‌های سرویس، نگهداری و تغییرات آینده را هم در نظر بگیرید.
پیش از توسعه، آزمون‌های پذیرش را بنویسید
برای هر جفت زبانی لازم، نمونه‌های معرف انتخاب کنید. پیام‌های طولانی، نویسه‌های غیرمعمول، فیلدهای خالی و اصطلاحات فهرست تأییدشده خود را بگنجانید. کل کار را، از رکورد مبدأ تا نتیجه ذخیره‌شده یا ارسال‌شده، آزمایش کنید.
معیارهای قبولی‌ای تعیین کنید که افراد بتوانند بررسی کنند: کدهای محصول بدون تغییر می‌مانند، ترجمه تأییدنشده قابل ارسال نیست، درخواست ناموفق قابل مشاهده است و بازبین می‌تواند به متن مبدأ برگردد. از یک بازبین واجد صلاحیت بخواهید معنا و لحن را ارزیابی کند. ایرادها را ثبت کنید و پس از تغییرات همان آزمون‌ها را تکرار کنید.
یک درخواست روشن برای پیشنهاد قیمت آماده کنید
گردش‌کار، فیلدهای نمونه، جفت‌های زبانی، حجم تخمینی، قواعد داده و آزمون‌های پذیرش را بفرستید. هر مورد را به‌عنوان الزامی برای راه‌اندازی یا مناسب برای نسخه‌ای بعدی علامت بزنید. فرض‌ها و موارد مستثنا را به‌صورت مکتوب بخواهید.
Vavus برای پروژه‌های سفارشی تعریف دامنه مکتوب ارائه می‌دهد. [4] از صفحه درخواست پیشنهاد قیمت برای توصیف اپلیکیشن فعلی خود و کاری که می‌خواهید بهبود دهید استفاده کنید. یکپارچه‌سازی، استقرار و آزمون پیشنهادی باید در دامنه پروژه شما تأیید شوند.