موجودہ بزنس ایپ میں ترجمہ انٹیگریشن کا دائرۂ کار کیسے طے کریں
اپنی بزنس ایپ میں ترجمے کی منصوبہ بندی کریں۔ کوٹیشن کی درخواست سے پہلے مواد، زبانیں، جائزہ، ڈیٹا کے قواعد، ناکامی سے نمٹنے کا طریقہ اور قبولیت کی جانچ طے کریں۔
کسی ایک مکمل کام سے شروع کریں جو آپ کی ٹیم کو کسی دوسری زبان میں کرنا ہوتا ہے۔ پھر طے کریں کہ ترجمہ اس کام میں کیسے شامل ہوگا۔ اس سے سافٹ ویئر سپلائر کو تخمینے کے لیے محض ترجمہ بٹن شامل کرنے کی درخواست سے زیادہ واضح بنیاد ملتی ہے۔
دائرۂ کار میں متن، لوگ، ڈیٹا اور نتیجہ شامل ہونا چاہیے۔ اس میں یہ بھی واضح ہونا چاہیے کہ ترجمہ ناکام ہونے پر کیا ہوتا ہے۔ تکنیکی طریقہ منتخب کرنے سے پہلے یہ دائرۂ کار تیار کرنے کے لیے نیچے دیے گئے مراحل استعمال کریں۔
پہلی ریلیز کے لیے ایک ورک فلو منتخب کریں
لکھیں کہ اصل متن کہاں سے آتا ہے اور منظور شدہ ترجمہ کہاں جانا چاہیے۔ مثال کے طور پر، سپورٹ کے کسی ملازم کو آنے والا پیغام پڑھنا اور کسٹمر کی زبان میں جواب تیار کرنا پڑ سکتا ہے۔ یہ ایک وضاحتی تقاضا ہے، کسی Vavus تنصیب کی رپورٹ نہیں۔
ہر مرحلہ درج کریں: پیغام کھولیں، ترجمے کی درخواست کریں، اصل متن کو نتیجے کے ساتھ رکھ کر پڑھیں، جواب میں ترمیم کریں اور بھیجنے کے لیے اسے منظور کریں۔ طے کریں کہ ترجمہ خود بخود شروع ہوگا یا صرف اس وقت جب کوئی ملازم اسے منتخب کرے۔
پہلی ریلیز چھوٹی رکھیں۔ ایک اسکرین اور ایک واضح کاروباری کام کی جانچ کسی ایپلیکیشن کے ہر متنی فیلڈ کی جانچ سے آسان ہوتی ہے۔
مواد اور زبانوں کی ضروریات کی نشاندہی کریں
ان فیلڈز کی فہرست بنائیں جن کا ترجمہ درکار ہے۔ مختصر لیبلز، آزاد متن، دستاویزات اور آواز کو الگ الگ رکھیں۔ ان کے لیے مختلف پروسیسنگ اور جانچ درکار ہو سکتی ہے۔ ان فیلڈز کی فہرست بھی بنائیں جو تبدیل نہیں ہونے چاہئیں، جیسے آرڈر نمبرز اور پروڈکٹ کوڈز۔
ماخذ اور ہدف زبانیں واضح کریں، بشمول کسی بھی علاقائی شکل کے۔ متن کی عام لمبائی اور متوقع روزانہ مقدار درج کریں۔ پوچھیں کہ مجوزہ سروس زبانوں کے کون سے امتزاج اور ان پٹ فارمیٹس سپورٹ کرتی ہے۔
مختصر متن کے لیے سیاق و سباق اہم ہو سکتا ہے۔ مثال کے طور پر، DeepL کا ٹیکسٹ API سیاق و سباق کا ایک پیرامیٹر سپورٹ کرتا ہے جو خود سیاق و سباق کا ترجمہ کیے بغیر ترجمے پر اثر ڈال سکتا ہے۔ اس کی دستاویزات میں یہ بھی بتایا گیا ہے کہ ایک ہی درخواست میں الگ الگ متنی اندراجات سیاق و سباق شیئر نہیں کرتے۔ [1] آپ کے دائرۂ کار میں یہ بتایا جانا چاہیے کہ مفید سیاق و سباق کہاں سے آئے گا۔
اصطلاحات اور انسانی جائزہ طے کریں
وہ اصطلاحات جمع کریں جو آپ کا کاروبار اکثر استعمال کرتا ہے۔ ترجیحی ترجمے، پروڈکٹ کے نام اور وہ الفاظ شامل کریں جو تبدیل نہیں ہونے چاہئیں۔ اس فہرست کی دیکھ بھال کے لیے ایک شخص مقرر کریں۔
کچھ ترجمہ سروسز گلاسری سپورٹ کرتی ہیں۔ Google Cloud Translation اپنی گلاسری کو ایک کسٹم لغت کے طور پر بیان کرتا ہے جو کسی مخصوص شعبے کی اصطلاحات کو یکساں رکھنے کے لیے ہے۔ [2] اپنی زبانوں کے مخصوص جوڑوں اور منتخب سروس کے لیے اس فیچر کی جانچ کریں۔ گلاسری اس بات کا ثبوت نہیں کہ پورا پیغام درست ہے۔
طے کریں کہ کن نتائج کے لیے زبان کے کسی اہل جائزہ کار کی ضرورت ہے۔ جائزہ کار کو اصل متن تک رسائی دیں۔ کسٹمرز کے سامنے جانے والا متن بھیجنے یا شائع کرنے سے پہلے منظوری کا ایک واضح مرحلہ مقرر کریں۔
ڈیٹا اور رسائی کے قواعد مقرر کریں
بیان کریں کہ ورک فلو کون سی معلومات سنبھالتا ہے۔ ابتدائی جانچ کے دوران فرضی مثالیں استعمال کریں۔ صرف یہ دیکھنے کے لیے کہ کوئی بٹن کام کرتا ہے یا نہیں، کسٹمرز کے اصل ریکارڈز آزمائش میں کاپی کرنے سے گریز کریں۔
پوچھیں کہ متن کہاں پروسیس ہوگا، ایپلیکیشن کیا محفوظ کرے گی، اسے کون پڑھ سکتا ہے اور اسے کب حذف کیا جائے گا۔ اس گفتگو میں لاگز اور بیک اپس کو بھی شامل کریں۔ فراہم کنندہ کی موجودہ شرائط اور منتخب پلان میں دستیاب کنٹرولز کی تصدیق کریں۔
کوئی کسٹم انٹرفیس بذاتِ خود کسی بیرونی ترجمہ سروس کو نجی یا آف لائن نہیں بناتا۔ اگر آپ کے پروجیکٹ کو مقامی پروسیسنگ درکار ہے تو یہ تقاضا شروع ہی میں بیان کریں اور ڈیٹا کے پورے بہاؤ کو اس کے مطابق جانچیں۔
تاخیر اور غلطیوں کے لیے منصوبہ بنائیں
متوقع جوابی وقت لکھیں، اور یہ بھی کہ سروس دستیاب نہ ہونے پر عملے کو کیا کرنا چاہیے۔ ایپلیکیشن کو واضح حالت دکھانی چاہیے، جیسے انتظار میں، جائزے کے لیے تیار یا ناکام۔ اصل متن محفوظ رکھیں۔
ڈیولپر سے کہیں کہ عارضی ناکامیوں اور ان غلطیوں میں فرق کرے جن کے لیے کوئی تبدیلی درکار ہو۔ مثال کے طور پر، DeepL ریٹ لمٹ کی غلطیوں کے لیے وقفے کے بعد دوبارہ کوشش کا طریقہ بیان کرتا ہے، جبکہ کوٹا ختم ہو جانے پر مختلف ردِعمل درکار ہوتا ہے۔ [3] بار بار کی درخواستوں سے کاروباری کارروائیاں دہرائی نہیں جانی چاہئیں، جیسے ایک ہی جواب دو بار بھیج دینا۔
استعمال کے الرٹس پر اور اس بات پر اتفاق کریں کہ سپورٹ کا ذمہ دار کون ہوگا۔ پروجیکٹ کی لاگت کا موازنہ کرتے وقت سروس چارجز، دیکھ بھال اور مستقبل کی تبدیلیاں بھی شامل کریں۔
ڈیولپمنٹ سے پہلے قبولیت کی جانچ لکھیں
زبانوں کے ہر مطلوبہ جوڑے کے لیے نمائندہ مثالیں منتخب کریں۔ لمبے پیغامات، غیر معمولی حروف، خالی فیلڈز اور اپنی منظور شدہ فہرست کی اصطلاحات شامل کریں۔ اصل ریکارڈ سے لے کر محفوظ کیے گئے یا بھیجے گئے نتیجے تک پورے کام کی جانچ کریں۔
کامیابی کے ایسے معیار مقرر کریں جنہیں لوگ خود جانچ سکیں: پروڈکٹ کوڈز تبدیل نہ ہوں، غیر منظور شدہ ترجمہ بھیجا نہ جا سکے، ناکام درخواست نظر آئے اور جائزہ کار اصل متن پر واپس جا سکے۔ مطلب اور لہجے کا جائزہ کسی اہل جائزہ کار سے کروائیں۔ نقائص درج کریں اور تبدیلیوں کے بعد وہی جانچ دہرائیں۔
کوٹیشن کے لیے واضح درخواست تیار کریں
ورک فلو، نمونہ فیلڈز، زبانوں کے جوڑے، متوقع مقدار، ڈیٹا کے قواعد اور قبولیت کی جانچ بھیجیں۔ ہر آئٹم پر واضح کریں کہ وہ لانچ کے لیے ضروری ہے یا بعد کی ریلیز کے لیے موزوں ہے۔ مفروضات اور شامل نہ کی گئی چیزیں تحریری طور پر طلب کریں۔
Vavus کسٹم پروجیکٹس کے لیے دائرۂ کار کا تحریری تعین پیش کرتا ہے۔ [4] کوٹیشن کے صفحے پر اپنی موجودہ ایپلیکیشن اور اس کام کی وضاحت کریں جسے آپ بہتر بنانا چاہتے ہیں۔ مجوزہ انٹیگریشن، تعیناتی اور جانچ کی تصدیق آپ کے پروجیکٹ کے دائرۂ کار میں کی جانی چاہیے۔