বিদ্যমান ব্যবসায়িক অ্যাপে অনুবাদ ইন্টিগ্রেশনের পরিধি কীভাবে ঠিক করবেন
আপনার ব্যবসায়িক অ্যাপে অনুবাদের পরিকল্পনা করুন। কোটেশন চাওয়ার আগে কনটেন্ট, ভাষা, পর্যালোচনা, ডেটার নিয়ম, ব্যর্থতা সামলানো ও গ্রহণযোগ্যতা পরীক্ষা ঠিক করুন।
এমন একটি সম্পূর্ণ কাজ দিয়ে শুরু করুন, যা আপনার টিমকে অন্য ভাষায় করতে হয়। তারপর ঠিক করুন, সেই কাজে অনুবাদ কীভাবে খাপ খায়। এতে একটি সফটওয়্যার সরবরাহকারী শুধু একটি অনুবাদ বোতাম যোগ করার অনুরোধের চেয়ে খরচ অনুমানের জন্য আরও স্পষ্ট ভিত্তি পান।
পরিধিতে লেখা, মানুষ, ডেটা ও ফলাফল থাকা উচিত। অনুবাদ ব্যর্থ হলে কী হবে, তারও ব্যাখ্যা থাকা উচিত। কোনো কারিগরি পদ্ধতি বেছে নেওয়ার আগে নিচের ধাপগুলো ধরে সেই পরিধি তৈরি করুন।
প্রথম রিলিজের জন্য একটি ওয়ার্কফ্লো বেছে নিন
মূল লেখা কোথা থেকে আসে এবং অনুমোদিত অনুবাদ কোথায় যেতে হবে, তা লিখে রাখুন। উদাহরণস্বরূপ, একজন সাপোর্ট কর্মীকে হয়তো আসা একটি বার্তা পড়ে গ্রাহকের ভাষায় উত্তর তৈরি করতে হয়। এটি একটি দৃষ্টান্তমূলক প্রয়োজনীয়তা, কোনো Vavus ইনস্টলেশনের বিবরণ নয়।
প্রতিটি ধাপ তালিকাভুক্ত করুন: বার্তা খোলা, অনুবাদ চাওয়া, ফলাফলের পাশে মূল লেখা পড়া, উত্তর সম্পাদনা করা এবং পাঠানোর জন্য অনুমোদন দেওয়া। অনুবাদ স্বয়ংক্রিয়ভাবে শুরু হবে, নাকি কোনো কর্মী বেছে নেওয়ার পরেই শুরু হবে, তা ঠিক করুন।
প্রথম রিলিজ ছোট রাখুন। একটি অ্যাপ্লিকেশনের প্রতিটি টেক্সট ফিল্ডের চেয়ে একটি স্ক্রিন ও একটি স্পষ্ট ব্যবসায়িক কাজ পরীক্ষা করা সহজ।
কনটেন্ট ও ভাষার প্রয়োজন চিহ্নিত করুন
যেসব ফিল্ড অনুবাদ করতে হবে, তার একটি তালিকা করুন। ছোট লেবেল, মুক্ত লেখা, ডকুমেন্ট ও কথা আলাদা করুন। এগুলোর জন্য ভিন্ন প্রসেসিং ও ভিন্ন পরীক্ষা লাগতে পারে। যেসব ফিল্ড অপরিবর্তিত থাকতে হবে, যেমন অর্ডার নম্বর ও প্রোডাক্ট কোড, সেগুলোরও তালিকা করুন।
আঞ্চলিক রূপসহ উৎস ও লক্ষ্য ভাষাগুলো নির্দিষ্ট করুন। লেখার সাধারণ দৈর্ঘ্য ও আনুমানিক দৈনিক পরিমাণ লিখে রাখুন। প্রস্তাবিত সার্ভিস কোন ভাষা-সমন্বয় ও ইনপুট ফরম্যাট সমর্থন করে, তা জিজ্ঞেস করুন।
ছোট লেখার ক্ষেত্রে প্রসঙ্গ গুরুত্বপূর্ণ হতে পারে। উদাহরণস্বরূপ, DeepL-এর টেক্সট API একটি context প্যারামিটার সমর্থন করে, যা প্রসঙ্গটিকে অনুবাদ না করেই অনুবাদকে প্রভাবিত করতে পারে। এর ডকুমেন্টেশনে আরও বলা আছে, একটি অনুরোধের আলাদা আলাদা টেক্সট এন্ট্রি প্রসঙ্গ ভাগ করে না। [1] কাজে লাগার মতো প্রসঙ্গ কোথা থেকে আসবে, আপনার পরিধিতে তা উল্লেখ থাকা উচিত।
পরিভাষা ও মানুষের পর্যালোচনা নির্ধারণ করুন
আপনার ব্যবসায় প্রায়ই ব্যবহৃত শব্দগুলো সংগ্রহ করুন। পছন্দের অনুবাদ, প্রোডাক্টের নাম এবং যেসব শব্দ অপরিবর্তিত থাকা উচিত, সেগুলো রাখুন। এই তালিকা হালনাগাদ রাখার দায়িত্ব একজনকে দিন।
কিছু অনুবাদ সার্ভিস গ্লসারি সমর্থন করে। Google Cloud Translation তার গ্লসারিকে নির্দিষ্ট ক্ষেত্রের পরিভাষা সামঞ্জস্যপূর্ণ রাখার জন্য একটি কাস্টম অভিধান হিসেবে বর্ণনা করে। [2] আপনার নির্দিষ্ট ভাষা-জোড়া ও বেছে নেওয়া সার্ভিসের জন্য ফিচারটি যাচাই করুন। গ্লসারি প্রমাণ করে না যে পুরো বার্তাটি সঠিক।
কোন আউটপুটগুলোর জন্য একজন যোগ্য ভাষা পর্যালোচক দরকার, তা ঠিক করুন। পর্যালোচককে মূল লেখায় অ্যাক্সেস দিন। গ্রাহকের কাছে যাওয়া লেখা পাঠানো বা প্রকাশ করার আগে একটি স্পষ্ট অনুমোদনের ধাপ রাখুন।
ডেটা ও অ্যাক্সেসের নিয়ম ঠিক করুন
ওয়ার্কফ্লোটি কোন তথ্য নিয়ে কাজ করে, তা বর্ণনা করুন। প্রাথমিক পরীক্ষায় কৃত্রিম উদাহরণ ব্যবহার করুন। একটি বোতাম কাজ করে কি না দেখার জন্য গ্রাহকের আসল রেকর্ড ট্রায়ালে কপি করবেন না।
জিজ্ঞেস করুন লেখা কোথায় প্রসেস করা হবে, অ্যাপ্লিকেশন কী সংরক্ষণ করবে, কে তা পড়তে পারবেন এবং কখন তা মুছে ফেলা হবে। এই আলোচনায় লগ ও ব্যাকআপও রাখুন। সরবরাহকারীর বর্তমান শর্তাবলি এবং বেছে নেওয়া প্ল্যানে কোন নিয়ন্ত্রণগুলো পাওয়া যায়, তা নিশ্চিত করুন।
একটি কাস্টম ইন্টারফেস নিজে থেকে কোনো বাইরের অনুবাদ সার্ভিসকে প্রাইভেট বা অফলাইন করে না। আপনার প্রকল্পে যদি লোকাল প্রসেসিং লাগে, তাহলে শুরুতেই সেই প্রয়োজনীয়তা জানিয়ে দিন এবং পুরো ডেটা প্রবাহ সেই অনুযায়ী পরীক্ষা করুন।
বিলম্ব ও ত্রুটির জন্য পরিকল্পনা করুন
প্রত্যাশিত রেসপন্স টাইম এবং সার্ভিস না পাওয়া গেলে কর্মীদের কী করতে হবে, তা লিখে রাখুন। অ্যাপ্লিকেশনে একটি স্পষ্ট অবস্থা দেখানো উচিত, যেমন অপেক্ষমাণ, পর্যালোচনার জন্য প্রস্তুত বা ব্যর্থ। মূল লেখা সংরক্ষণ করুন।
ডেভেলপারকে বলুন সাময়িক ব্যর্থতা আর পরিবর্তন প্রয়োজন এমন ত্রুটির মধ্যে পার্থক্য করতে। উদাহরণস্বরূপ, DeepL রেট-লিমিট ত্রুটির ক্ষেত্রে কিছুটা দেরিতে পুনরায় চেষ্টার কথা নথিভুক্ত করেছে, অথচ কোটা শেষ হয়ে গেলে ভিন্ন প্রতিক্রিয়া দরকার। [3] বারবার অনুরোধের কারণে যেন ব্যবসায়িক কোনো কাজ দ্বিগুণ না হয়, যেমন একই উত্তর দুবার পাঠানো।
ব্যবহার-সংক্রান্ত সতর্কবার্তা এবং সাপোর্টের দায়িত্ব কার, তা নিয়ে একমত হন। প্রকল্পের খরচ তুলনা করার সময় সার্ভিসের চার্জ, রক্ষণাবেক্ষণ ও ভবিষ্যৎ পরিবর্তনও ধরুন।
ডেভেলপমেন্টের আগে গ্রহণযোগ্যতা পরীক্ষা লিখুন
প্রতিটি প্রয়োজনীয় ভাষা-জোড়ার জন্য প্রতিনিধিত্বমূলক উদাহরণ বেছে নিন। লম্বা বার্তা, অস্বাভাবিক অক্ষর, খালি ফিল্ড এবং আপনার অনুমোদিত তালিকার শব্দ রাখুন। মূল রেকর্ড থেকে শুরু করে সংরক্ষিত বা পাঠানো ফলাফল পর্যন্ত পুরো কাজটি পরীক্ষা করুন।
এমন পাসের মানদণ্ড ঠিক করুন যা মানুষ যাচাই করতে পারেন: প্রোডাক্ট কোড অপরিবর্তিত থাকে, অননুমোদিত অনুবাদ পাঠানো যায় না, ব্যর্থ অনুরোধ দৃশ্যমান থাকে এবং পর্যালোচক মূল লেখায় ফিরে যেতে পারেন। একজন যোগ্য পর্যালোচককে দিয়ে অর্থ ও সুর মূল্যায়ন করান। ত্রুটিগুলো লিখে রাখুন এবং পরিবর্তনের পর একই পরীক্ষাগুলো আবার করুন।
কোটেশনের জন্য একটি স্পষ্ট অনুরোধ তৈরি করুন
ওয়ার্কফ্লো, নমুনা ফিল্ড, ভাষা-জোড়া, আনুমানিক পরিমাণ, ডেটার নিয়ম ও গ্রহণযোগ্যতা পরীক্ষা পাঠান। প্রতিটি বিষয় চালুর জন্য আবশ্যক নাকি পরের কোনো রিলিজের জন্য উপযুক্ত, তা চিহ্নিত করুন। অনুমান ও বাদ পড়া বিষয়গুলো লিখিতভাবে চান।
Vavus কাস্টম প্রকল্পের জন্য লিখিত পরিধি নির্ধারণের সুযোগ দেয়। [4] কোটেশন পেজে আপনার বিদ্যমান অ্যাপ্লিকেশন এবং যে কাজটি উন্নত করতে চান, তা বর্ণনা করুন। প্রস্তাবিত ইন্টিগ্রেশন, ডিপ্লয়মেন্ট ও টেস্টিং আপনার প্রকল্পের পরিধিতে নিশ্চিত করা উচিত।