ওয়েব ও নেটিভ UI-এর জন্য টেকসই লোকালাইজেশন ওয়ার্কফ্লো

লোকালাইজেশন যখন অপরিচালিত থাকে তখন কী ভুল হয়\n\nঅপরিচালিত লোকালাইজেশন প্রথমে ছোট, বিরক্তিকর সমস্যায় ভেঙে পড়ে, পরে ব্যয়বহুল সমস্যায়। যে লেবেলটি গতকাল ঠিক ছিল আজ তা ওভারফ্লো করে যেতে পারে। একটি মিসিং কী রা-আইডেন্টিফায়ার হিসেবে দেখা দেয়। ইংরেজিতে ঠিক শোনানো একটি বহুবচন অন্য ভাষায় বাজে বা অসম্মানজনকও হতে পারে।\n\nঅধিকাংশ টিম চাপের মধ্যে একই সমস্যা বারবার ঠিক করে:\n\n- কাটাকাটি বোতাম, ছেঁড়া হেডার, বা আইকনের উপর টেক্সট ওভারল্যাপ করা\n- মিসিং কী যা ইংরেজিতে ফ্লব্যাক করে বা কী-নাম দেখায়\n- ভুল বহুবচন ফর্ম (উদাহরণ: '1 items') এবং লিঙ্গভিত্তিক ভাষায় ভাঙ্গা ব্যাকরণ\n- একই ধারণার মাল্টি-স্ক্রিনে অসংগত শব্দচয়ন\n- শেষ মুহূর্তের হটফিক্স কারণ একটি স্ক্রিন অনুবাদ ছাড়া পাঠানো হয়েছে\n\nওয়েব এবং নেটিভ স্ক্রিন প্রায়ই ভিন্নভাবে ব্যর্থ হয়। ওয়েবে নমনীয় লেআউট সমস্যা লুকিয়ে রাখতে পারে যতক্ষণ না কোনো নির্দিষ্ট ভিউপোর্ট বা ব্রাউজার সেটা তুলে ধরে। টেক্সট অপ্রত্যাশিতভাবে লাগানো, বোতাম নিচে ঠেলে দেওয়া বা গ্রিড ভাঙ্গা দেখা যায়। নেটিভ অ্যাপে স্পেসিং বেশি কড়া। একটি দীর্ঘ অনুবাদ গুরুত্বপূর্ণ উপাদান স্ক্রিন থেকে ঠেলে দিতে পারে, অ্যাক্সেসিবিলিটি ফন্ট সাইজের সঙ্গে সংঘর্ষ করতে পারে বা কাটা পড়তে পারে কারণ কম্পোনেন্ট স্বয়ংক্রিয়ভাবে রিসাইজ করে না।\n\nএকটি শক্তিশালী লোকালাইজেশন ওয়ার্কফ্লো এসবের বেশিরভাগ প্রতিরোধ করে: কী স্থিতিশীল করে, অনুবাদগুলো রিভিউবল করে এবং UI চেক রুটিন করে। এতে আপডেট দ্রুত আসে এবং অপ্রত্যাশিততা কমে। যা ঠিক করতে পারে না তা হল অস্পষ্ট সোর্স টেক্সট। যদি মূল কপি অস্পষ্ট হয় (যেমন 'Open' বা 'Apply' কোন প্রসঙ্গে), অনুবাদ তখনও অনুমানই হবে।\n\nসাফল্যের সহজ সংজ্ঞা 'সবকিছু অনুবাদিত' নয়। এটি হল:\n\n- UI ওয়েব ও নেটিভ স্ক্রিনে পাঠযোগ্য থাকে\n- কী গুলো দ্রুত পরিবর্তন করা যায় না বলে আপডেট দ্রুত হয়\n- QA ব্যবহারকারীর আগে সমস্যা খুঁজে পায়\n\nউদাহরণ: যদি কার্ট স্ক্রিনে ' {count} item(s)' দেখায়, অপরিচালিত স্ট্রিং থেকে অদ্ভুত বহুবচন এবং ভাঙ্গা স্পেসিং হবে। একটি পরিচালিত পদ্ধতি সঠিক বহুবচন নিয়ম জোর করে এবং রিলিজের আগে জার্মানিতে বোতাম ৩০% বড় হয়ে যাওয়াটাও ধরবে।\n\n## মালিকানা নির্ধারণ এবং একক সত্যের উত্স নির্বাচন\n\nলোকালাইজেশন ওয়ার্কফ্লো সবচেয়ে দ্রুত ভেঙে পড়ে যখন কেউ এক প্রশ্নের উত্তর দিতে পারে না: 'কোন টেক্সটই আসল?' একটি একক সোর্স-অফ-ট্রুথ বেছে নিন এবং সেটা নীরসভাবে স্পষ্ট করুন। সেই সোর্স হতে পারে রেপো ফাইল, অনুবাদ প্ল্যাটফর্ম বা একটি ইন্টারনাল টেবিল — কিন্তু এটা একটি জায়গা হতে হবে যা প্রতিটি বিবাদের বিরোধ মিটাবে।\n\nভূমিকা সিদ্ধান্তের উপর ভিত্তি করে নির্ধারণ করুন, চাকরির টাইটেলের উপর নয়। কেউকে অর্থ ও টোন অনুমোদন করতে হবে (সাধারণত Product বা Marketing)। কেউকে কী স্থিতিশীল রাখা ও কোডে ব্যবহারযোগ্য রাখার দায় নিতে হবে (সাধারণত Engineering)। কেউকে UI সীমা রক্ষা করতে হবে (সাধারণত Design), বিশেষ করে যখন ওয়েব ও নেটিভ আলাদা আচরণ করে।\n\nএকটি বিভাজন যা বেশিরভাগ দ্বন্দ্ব এড়ায়:\n\n- কী নির্মাতা: যে ব্যক্তি স্ক্রিন চালু করছে সে নতুন কী তৈরি করে যখন UI-তে নতুন টেক্সট দরকার।\n- শব্দ অনুমোদনকারী: একটি PM বা কপি কর্তৃপক্ষ বেস ভাষায় চূড়ান্ত টেক্সট অনুমোদন করে।\n- অনুবাদ এডিটর: অনুবাদকরা অনুবাদ বদলাতে পারে, কিন্তু কী নাম বদলাতে পারবে না।\n- কী পরিবর্তন: শুধুমাত্র কী-ওনার কীকে ডিপ্রিকেট বা মার্জ করার অনুমতি থাকবে, কারণ ব্যাখ্যাসহ নোট থাকতে হবে কেন।\n\nরিলিজগুলো আটকে না পড়ার জন্য প্রত্যাশিত প্রতিক্রিয়া সময় নির্ধারণ করুন। উদাহরণ: নতুন কী অনুরোধ 1 কর্মদিবসের মধ্যে স্বীকার, সোর্স ওয়ার্ডিং 2 দিনের মধ্যে অনুমোদন, এবং ক্রিটিক্যাল ফিক্স (ভাঙা UI, ভুল লিগ্যাল টেক্সট) কয়েক ঘণ্টার মধ্যে।\n\nকংক্রিট উদাহরণ: আপনার টিম একটি নতুন 'Reset password' ফ্লো বানায় ওয়েব ও নেটিভের জন্য। ডেভেলপার কী যুক্ত করে, PM চূড়ান্ত ইংরেজি টেক্সট অনুমোদন করে, এবং অনুবাদকরা অন্যান্য ভাষা পূরণ করে। যদি অনুবাদক লক্ষ্য করে 'Reset' হওয়ার বদলে 'Change' হওয়া উচিত, তারা অনুবাদ жаң করে কিন্তু কী একই থাকে। যদি PM একই টেক্সট বিভিন্ন স্ক্রিনে পুনরায় ব্যবহার করতে চান, শুধু কী-ওনার সেই কাঠামোগত পরিবর্তন করবেন যাতে কিছু নীরবভাবে ভাঙ্গে না।\n\n## কী কৌশল: পুনরায় ব্যবহার, স্থিতিশীলতা এবং স্ক্রিন সীমানা\n\nএকটি ভাল লোকালাইজেশন ওয়ার্কফ্লো এক নিয়ম দিয়ে শুরু করে: কী গুলো আইডেন্টিফায়ার, ইংরেজি বাক্য নয়। সেগুলোকে পার্ট নাম হিসেবে ট্রিট করুন। যদি পরবর্তীতে শব্দ বদলে যায়, সাধারণত কী একই থাকা উচিত।\n\nঅর্থ বদলে গেলে নতুন কী তৈরি করুন। যখন অর্থ একই থাকে তখন কী পুনরায় ব্যবহার করুন, এমনকি স্ক্রিন আলাদা থাকলেও। 'Save' প্রোফাইল স্ক্রিনে এবং 'Save' সেটিংস স্ক্রিনে একই অর্থ রাখলে তারা একই কী শেয়ার করতে পারে। কিন্তু 'Save' যদি 'bookmark' বোঝায় তাহলে আলাদা কী হওয়া উচিত, কারণ অনুবাদকরা ভিন্ন ক্রিয়া দরকার হতে পারে।\n\nসংক্ষিপ্ত UI লেবেলগুলোকে দীর্ঘ কন্টেন্ট থেকে আলাদা রাখুন। একটি বোতামের লেবেল, হেল্পার হিন্ট এবং এরর মেসেজ প্রায়শই ভিন্নভাবে অনূদিত হয় এবং ভিন্ন দৈর্ঘ্য সীমা থাকে। আলাদা কী রাখলে টোন ও পাংচুয়েশন বদলানো সহজ হয় অন্য স্ক্রিন ভাঙানোর ঝুঁকি ছাড়া।\n\n### স্ক্রিন সীমানা প্ল্যাটফর্মকে একই ভাষা জোর না করে\n\nওয়েব ও নেটিভ উভয়ের মধ্যে পুনরায় ব্যবহার লক্ষ্য করুন, কিন্তু যখন প্ল্যাটফর্ম ভিন্ন ভাষা চায় তখন তা জোর করবেন না। একটি নেটিভ পারমিশন প্রম্পট প্রায়ই ওয়েব টুলটিপের তুলনায় পরিষ্কার, আরও ফরমাল টেক্সট চাইতে পারে। সেই ক্ষেত্রে মূল ধারণা বজায় রেখে প্ল্যাটফর্ম-নির্দিষ্ট কী রাখুন যাতে প্রতিটি UI স্বাভাবিকভাবে পড়ে।\n\nপ্রায়োগিক প্যাটার্ন: ফিচার ও UI টাইপ অনুযায়ী কী গ্রুপ করুন, তারপর ওই সীমানার ভিতরে পুনরায় ব্যবহার করুন:\n\n- একই ফিচারের মধ্যে পুনরায় ব্যবহার করুন যদি অর্থ একদম একই\n- UI টাইপ অনুযায়ী কী আলাদা করুন (লেবেল বনাম হেল্প বনাম এরর বনাম সিস্টেম প্রম্পট)\n- যখন বাক্যতথ্য আলাদা হওয়া দরকার তখন প্ল্যাটফর্ম ভ্যারিয়েন্ট ব্যবহার করুন\n- কী স্থিতিশীল রাখুন এবং শুধুমাত্র প্রদর্শিত টেক্সট পরিবর্তন করুন\n- যে জায়গায় দেখা যায় সেখানে কনটেক্সট নোট যোগ করুন (কোথায় প্রদর্শিত হবে, ক্যারেক্টার লিমিট)\n\nউদাহরণ: একই 'Delete customer' অ্যাকশন ওয়েব অ্যাডমিন প্যানেল ও নেটিভ ফিল্ড অ্যাপে থাকতে পারে। আপনি কোর অ্যাকশন লেবেল পুনরায় ব্যবহার করতে পারেন, কিন্তু নেটিভ কনফার্মেশন টেক্সট যদি শক্ততর সতর্কতা বা ছোট লাইনের প্রয়োজন হয় তবে আলাদা কী রাখবেন।\n\n## অনুবাদ কী-এর নামকরণ ও সংগঠন\n\nআমি একটি ভাল নামকরণ সিস্টেম লোকালাইজেশনকে 'ভালোভাবে বিরক্তিকর' করে তোলে: মানুষ দ্রুত স্ট্রিং খুঁজে পায়, অনুবাদকরা প্রসঙ্গ পায়, এবং কী স্থিতিশীল থেকে যায় যখন কপি বদলে যায়।\n\nএকটি পাঠযোগ্য কনভেনশন ব্যবহার করুন যা চারটি প্রশ্নের উত্তর দেয়: কোথায় আছে, কী, কী উদ্দেশ্য, এবং এটা কি ভ্যারিয়েন্ট। একটি সহজ প্যাটার্ন যা ওয়েব ও নেটিভ উভয়েই কাজ করে:\n\n<product_or_domain>.<screen_or_flow>.<component>.<purpose>[.<variant>]\n\nউদাহরণ, কাস্টমার পোর্টালে: portal.login.button.submit বা portal.orders.empty_state.title. এটা কী গুলোকে স্ক্রিন বা ফ্লো অনুযায়ী গ্রুপ করে রাখে এবং কম্পোনেন্ট অনুসারে সার্চ করা সহজ করে।\n\nখারাপ কী হয় বা অত্যন্ত অস্পষ্ট বা বর্তমান ইংরেজি টেক্সটের ওপর খুব আবদ্ধ:\n\n- ভাল: portal.profile.field.email.label\n- খারাপ: emailText (কোন স্কোপ নেই, উদ্দেশ্য নেই)\n- খারাপ: please_enter_your_email (কপি বদলে গেলে ভাঙে)\n- ভাল: portal.checkout.error.payment_failed\n- খারাপ: error_12\n\nভ্যারিয়েন্টগুলো স্পষ্ট হওয়া উচিত, পাংচুয়েশন বা কেস মিশিয়ে হ্যাক করা উচিত নয়। যদি মোবাইল হেডারের জন্য ছোট লেবেল দরকার হয়, ভ্যারিয়েন্ট সাফিক্স যোগ করুন: ...title.short বনাম ...title.long। কেস পার্থক্য দরকার হলে আলাদা কী ব্যবহার করুন যেমন ...button.save এবং ...button.save_titlecase শুধুমাত্র যখন প্ল্যাটফর্ম সেফলি ট্রান্সফর্ম করতে না পারে।\n\nপ্লেসহোল্ডারগুলোর নিয়মও থাকা চাই যাতে অনুবাদক অনুমান না করে:\n\n- নামকৃত প্লেসহোল্ডার ব্যবহার করুন: {user_name}, {count}, {date}\n- কখনই কনক্যাটেনেট করবেন না: 'Hello ' + name তৈরি করবেন না\n- ইউনিটগুলো ভাষাভিত্তিক হলে স্ট্রিংয়ের ভিতরেই রাখুন: {count} items না করে {count} + ' items' নয়\n- অনুমোদিত ফরম্যাট সংজ্ঞায়িত করুন: ISO তারিখ, মুদ্রা, বা প্ল্যাটফর্ম-নির্দিষ্ট তারিখ ফরম্যাটিং\n- জটিল স্ট্রিংয়ের জন্য সংক্ষিপ্ত নোট যোগ করুন (যেমন {count} শূন্য হতে পারে কি না)\n\n## বহুবচন ও ব্যাকরণ নিয়ম যা পুনরায় কাজ বাঁচায়\n\nবহুবচন হল যেখানে ওয়ার্কফ্লো প্রথমে ভেঙে যায়। অনেক টিম ধরেন প্রতিটি ভাষায় শুধু 'one' ও 'other' আছে, পরে দেখা যায় UI অদ্ভুত শোনায় বা শেষ মুহূর্তের ফিক্স লাগে।\n\nভাষাগুলোতে একাধিক বহুবচন ক্যাটাগরি থাকতে পারে। ইংরেজি সাধারণত 'one' ও 'other' ব্যবহার করে, কিন্তু রাশিয়ান, পোলিশ, আরবি ও চেকের মতো ভাষায় 'few', 'many' বা 'zero' ধরনের ফর্ম দরকার হতে পারে। যদি আপনি প্রথমেই একটি সিঙ্গল প্যাটার্ন হার্ডকোড করেন, পরে কেবল ওয়েব ও নেটিভে স্ট্রিংগুলো পুনরায় লেখার প্রয়োজন পড়ে।\n\nএকটি স্ট্যান্ডার্ড বেছে নিন এবং সব জায়গায় তারই ব্যবহার করুন (ওয়েব, iOS, Android, ব্যাকএন্ড-রেন্ডারড টেক্সট)। প্রায়োগিক পন্থা: পৃথক ফর্মের জন্য আলাদা কী রাখার বদলে এক কী-তে বহুবচন ফর্মগুলো সংরক্ষণ করুন। CLDR ক্যাটেগরির উপর ভিত্তি করে ফর্মগুলোর সেট রাখুন যাতে বাস্তব ভাষার নিয়ম মিলে যায়।\n\nএকটি নিয়ম যা পুনরায় কাজ ঠেকায়: কখনই UI বাক্য টুকরো করে বানাবেন না যেমন 'You have ' + count + ' messages'. শব্দের ক্রম বদলতে পারে, এবং কিছু ভাষায় সংখ্যা অনুযায়ী শেষ ইঙ্গিত বা কেস লাগে।\n\n### প্রায়োগিক কী প্যাটার্ন\n\nমেসেজ কাউন্টার জন্য একটি স্থিতিশীল কী নির্ধারণ করুন এবং সংখ্যা প্যারামিটার হিসেবে রাখুন। তারপর প্রতিটি ভাষার অনুবাদক প্রয়োজনীয় ফর্ম সরবরাহ করবেন।\n\n- এক তত্ত্বের জন্য একটি কী ব্যবহার করুন (উদাহরণ: inbox.message_count)\n- CLDR ফর্মগুলো সমর্থন করুন (zero, one, two, few, many, other)\n- সারাক্ষণ প্লেসহোল্ডার ব্যবহার করুন (উদাহরণ: {count}) পুরো বাক্যের ভিতরে\n- অনুবাদকারী নোট যোগ করুন যখন অর্থ অস্পষ্ট (এটা 'messages' না 'unread messages'?)\n\n### লিঙ্গ এবং ব্যাকরণিক কেস\n\nকখনো কখনো বহুবচন যথেষ্ট হয় না। যদি আপনার UI কোনো ব্যক্তিকে সম্বোধন করে ('Welcome, Alex') বা ভূমিকা উল্লেখ করে ('assigned to him/her'), কিছু ভাষায় ভিন্ন শব্দ দরকার হবে লিঙ্গ অনুযায়ী। অন্য ভাষায় নির্দিষ্ট প্রিপজিশনের পরে ব্যাকরণিক কেস বদলে যায়।\n\nএমন হলে সত্যিকারের ভিন্ন ব্যাকরণের জন্য আলাদা স্ট্রিং তৈরি করুন, কেবল স্টাইলের জন্য নয়। লক্ষ্য হচ্ছে কম কী রাখা, কিন্তু QA তে অপ্রত্যাশিত পরিস্থিতি কম রাখা যাতে 'সঠিক' অনুবাদও প্রসঙ্গে ভুল না লাগে।\n\n## প্ল্যাটফর্ম জুড়ে ফরম্যাটিং ও লেআউট সীমাবদ্ধতা\n\nএকটি অনুবাদ সঠিক হলেও UI ভাঙিয়ে দিতে পারে। ওয়েব ও নেটিভ অ্যাপ টেক্সট ভিন্নভাবে রেন্ডার করে, তাই আপনার ওয়ার্কফ্লোতে ফরম্যাটিং নিয়ম ও লেআউট চেক থাকা উচিত, শুধু অনুবাদ নয়।\n\nসংখ্যা, টাকা ও তারিখ প্রদর্শনের জন্য স্ট্যান্ডার্ডাইজ করুন। কনক্যাটেনেশন এড়ান যেমন '$' + amount বা লেবেলে হার্ডকোড করা তারিখ ফরম্যাট। লোকেল-সচেতন ফরম্যাট ব্যবহার করুন যাতে সেপারেটর ও ক্রম মিলবে (1,000.50 বনাম 1 000,50; দিন-মাস-বছর বনাম মাস-দিন-বছর)। টাইমজোন সাধারণত জটিল: টাইমস্ট্যাম্প UTC-তে স্টোর করুন, ব্যবহারকারীর লোকালের জোনে রেন্ডার করুন, এবং স্পষ্ট করুন যদি কোনো সময় নির্দিষ্ট জোন নির্দেশ করে (যেমন স্টোর পিকআপ টাইম)।\n\nটেক্সট ডিরেকশন আরেকটি নীরব ভাঙা। যদি আপনি রাইট-টু-লেফট (RTL) সাপোর্ট করেন, আয়না করা লেআউট ও চলন্ত পাংচুয়েশন পরিকল্পনা করুন। নির্দেশ বোঝাতে যে আইকনগুলো (তীর, ব্যাক বোতাম, প্রোগ্রেস স্টেপ) প্রায়ই ফ্লিপ করতে হয়। একটি দ্রুত RTL পাস রিভিউর অংশ করুন, এমনকি পুরোপুরি RTL সাপোর্ট না থাকলেও।\n\nমোবাইলে ফন্ট ও স্পেসিং ওয়েবের চেয়েও বেশি বদলে যেতে পারে। একটি স্ট্রিং যা ওয়েবে ফিট করে নেটিভে কুৎসিতভাবে র্যাপ করতে পারে। নিরাপদ ন্যুনতম ফন্ট সাইজ সিদ্ধান্ত নিন, যেখানে যুক্তিযুক্ত সেখানে লেবেল র্যাপ করার অনুমতি দিন, এবং ডিফল্ট ফন্ট আপনার স্ক্রিপ্ট কভার না করলে ফেলব্যাক ফন্ট নির্ধারণ করুন।\n\nঅ্যাক্সেসিবিলিটি-ও লোকালাইজড চেক দাবি করে। স্ক্রিন রিডার সংখ্যা, সংক্ষিপ্ত রূপ ও মিশ্র-ভাষার টেক্সট অদ্ভুতভাবে পড়তে পারে।\n\nলেআউট গার্ডরেইল যা বেশিরভাগ সমস্যা প্রতিরোধ করে:\n\n- টেক্সট এক্সপ্যানশনের জন্য ডিজাইন করুন (৩০–৫০% বেশি) এবং স্থির চওড়ার বোতামের ব্যবহার কমান।\n- ডায়নামিক মান (কাউন্ট, দাম, তারিখ) আলাদা ফরম্যাটেড টোকেনে রাখুন।\n- কাস্টম প্যাটার্ন নয়, প্ল্যাটফর্ম-নেটিভ তারিখ ও সংখ্যা ফরম্যাটার ব্যবহার করুন।\n- রিলিজের আগে একটি RTL লোকেল ও একটি 'লম্বা টেক্সট' লোকেল টেস্ট করুন।\n- কোর ফ্লোতে স্ক্রিন-রিডার চেক চালান (লগইন, চেকআউট, সেটিংস)।\n\nউদাহরণ: 'Total: $1,234.50' লেবেলটি হতে পারে '1 234,50 €' যেখানে প্রতীক মানের পরে আসে, ভিন্ন স্পেসিং থাকে, এবং স্ক্রিন রিডারের জন্য 'Total' এবং পরিমাণের মধ্যে একটি বিরতি দরকার।\n\n## নতুন স্ক্রিন থেকে রিলিজ পর্যন্ত ধাপে ধাপে ওয়ার্কফ্লো\n\nলোকালাইজেশন ওয়ার্কফ্লো সাধারণত সেই সময় থেকে শুরু করতে হয় যখন স্ক্রিন এখনও ডিজাইনে আছে। যদি আপনি 'ডান' না হওয়া পর্যন্ত অপেক্ষা করেন, অনুবাদ তাড়াহুড়ো করে করতে হবে, কাটা টেক্সট পাঠাতে হবে বা 'ফিল-ফর-নাউ' বলে স্ট্রিং হার্ডকোড করতে হবে।\n\nপ্রতি লেবেল, বোতাম এবং মেসেজ ডিজাইন করার সময়ই একটি ট্রান্সলেশন কী যোগ করুন। বেস ভাষায় ডিফল্ট টেক্সট লিখুন এবং দ্রুত কনটেক্সট যোগ করুন যেমন কোথায় দেখা যাবে এবং কি কাজ করে। একটি কী যেমন checkout.pay_button তখনই ব্যবহারযোগ্য যখন অনুবাদকরা জানেন এটা একটি ক্রিয়া ('Pay') না একটি লেবেল ('Payment')।\n\nUI-টি প্লেসহোল্ডার ব্যবহার করে ইমপ্লিমেন্ট করুন এবং ডিফল্ট ভাষাকে ফেলব্যাক হিসেবে রাখুন। ভেরিয়েবলগুলি স্পষ্ট রাখুন (যেমন {name} বা {count}) এবং বাক্য টুকরা করে জোড়া করবেন না। এটি ব্যাকরণ ভাঙার দ্রুততম পথগুলোর একটি।\n\nস্ট্রিং অনুবাদের জন্য পাঠানোর সময় অনুবাদককে যা দরকার তা যোগ করুন: প্রতিটি স্ক্রিনের স্ক্রিনশট (বা যদি টেক্সট পরিবর্তন হয় তাহলে ছোট ভিডিও), টাইট স্পটগুলোর ক্যারেক্টার লিমিট (ট্যাব, বোতাম, ব্যাজ), টোন ও টার্মিনোলজির নোট, এবং ডায়নামিক প্লেসহোল্ডারগুলোর তালিকা ও তাদের অর্থ।\n\nঅনুবাদ এলে, সেগুলো দ্রুত মার্জ করুন এবং উভয় ওয়েব ও নেটিভ সংস্করণ তৈরি করুন। সবচেয়ে ঝুঁকিপূর্ণ স্ক্রিনগুলোতে দ্রুত UI চেক চালান: লগইন, অনবোর্ডিং, চেকআউট, এবং সেটিংস। কাটা টেক্সট, ওভারল্যাপ, মিসিং কী এবং ভুল বহুবচন খুঁজুন।\n\nঅবশেষে, রিলিজ করুন এবং মনিটর করুন। মিসিং কী, ডিফল্টে ফেরত যাওয়ার ইভেন্ট ও এমন স্ক্রিন যেখানে টেক্সট প্রায়ই ওভারফ্লো করে সেগুলো ট্র্যাক করুন।\n\n## অনুবাদকদের যা দরকার তা দিন যাতে তারা সঠিক অনুবাদ করতে পারে\n\nসঠিক অনুবাদ শুরু হয় একওয়াক্ত অনুবাদিত হওয়ার আগে। যদি অনুবাদকরা কেবল একটি কী ও একটি ইংরেজি বাক্য দেখে, তারা অনুমান করে। তাই কন্টেক্সট ভিন্ন জায়গায় সঠিক শব্দ ব্যবহার না হলে ভুল যায়।\n\nপ্রতি স্ট্রিংয়ের জন্য একটি সিম্পল 'কন্টেক্সট প্যাক' বেশিরভাগ অনুমান দূর করে। প্রতিটি স্ট্রিংয়ের জন্য যোগ করুন কোথায় দেখায় (স্ক্রিন ও কম্পোনেন্ট), ব্যবহারকারী কি করতে চায়, এবং টোন (বন্ধুসুলভ, আনুষ্ঠানিক, জরুরি)। এছাড়াও স্পষ্ট করুন এটা বোতামের লেবেল, এরর মেসেজ, মেনু আইটেম, নাকি হেল্পার টেক্সট — এই ক্যাটাগরি গুলো ভিন্নভাবে অনূদিত হয়।\n\nযখন জায়গা তীব্র ছোট, আগেই বলুন। ওয়েব ও নেটিভ ভিন্নভাবে ভাঙে, তাই জায়গার সীমা নির্ধারণ করুন: ছোট বোতাম লেবেল, ট্যাব টাইটেল, টোয়াস্ট, এবং ফিক্সড কার্ডের ভিতরের যেকোনো জিনিস। যদি একটি স্ট্রিং এক লাইনে থাকতে হবে, সেটা উল্লেখ করুন। যদি লাইনে ব্রেক করা যায়, কোন জায়গায় নিরাপদ তা বলুন।\n\n'অনুবাদ করবেন না' অংশগুলো স্পষ্ট করে দিন। প্রোডাক্ট নাম, প্ল্যান নাম, কুপন কোড, API ফিল্ড ও প্লেসহোল্ডার {name} ইত্যাদি অপরিবর্তনীয় রাখুন। নির্দেশ ছাড়া অনুবাদকরা সেগুলো লোকালাইজ করতে পারে এবং আপনার অ্যাপ অর্থবোধকতা হারাবে।\n\nপ্রতি স্ট্রিংয়ের জন্য একটি ব্যবহারিক প্যাকেজ:\n\n- স্ক্রিনশট বা স্ক্রিন নাম (উদাহরণ: 'Checkout - Payment method')\n- টাইপ ও উদ্দেশ্য (যেমন পেমেন্ট নিশ্চিত করার বোতাম)\n- টোন নোট (শান্ত, আশ্বস্তকারী)\n- সীমাবদ্ধতা (অধিকতম 18 ক্যারেক্টার, এক লাইন)\n- প্রোটেক্টেড টোকেন (প্রোডাক্ট নাম, ইন্টিগ্রেশন, {amount})\n\nলিগ্যাল টেক্সট ও সাপোর্ট কন্টেন্ট আলাদা স্ট্রিম করা ভাল। লিগ্যাল কপি প্রায়শই অনুমোদনের দাবি রাখে ও ধীর আপডেট হয়, তাই সেটাকে প্রোডাক্ট UI স্ট্রিং থেকে আলাদা ও ভার্সন-বদ্ধ রাখুন। সাপোর্ট আর্টিকেল ও হেল্প স্নিপেট সাধারণত দীর্ঘ অনুবাদ লাগে এবং আলাদা সিস্টেমে রাখা যায়।\n\nউদাহরণ: মোবাইলে একটি 'Continue' বোতাম ওয়েবের থেকে কঠোর সীমা চাইতে পারে। অনুবাদকরা যদি সেটা জানে, তারা এমন ছোট ক্রিয়া বেছে নেবে যেগুলো লম্বা ভাষায়ও ফিট করে এবং শেষ মুহূর্তের UI রিডিজাইন এড়াবে।\n\n## QA ও রিভিউ লুপ যা ভাঙা UI আটকায়\n\nলোকালাইজেশন থেকে UI ভাঙা হওয়া কমবেশি 'বাগ' দেখায় না। প্রথমে এগুলো দেখা যায় মিসিং লেবেল, দুলাই লাইন করা বোতাম, বা ভুল প্লেসহোল্ডার হিসেবে। একটি ভাল ওয়ার্কফ্লোতে QA ধাপ থাকে যা ব্যবহারকারীর আগে এসব সমস্যা তুলে ধরে।\n\nডেভেলপমেন্ট বিল্ডে পসুডো-লোকালাইজেশন দিয়ে শুরু করুন। বাস্তব স্ট্রিংগুলোকে লম্বা, অ্যাকসেন্টেড ভার্সন দিয়ে বদলে দিন (যেমন '[!!! Šéttïñĝš !!!]') এবং দৈর্ঘ্য ৩০–৫০% বৃদ্ধি করুন। এটি দ্রুত ট্রাঙ্কেশন, ওভারল্যাপ ও হার্ডকোডেড স্ট্রিং উভয় ওয়েব ও নেটিভে আবিষ্কার করে।\n\nপ্রতিটি বিল্ডে অটোমেটেড চেক যোগ করুন। এগুলো নির্দিষ্ট, ক্লান্তিকর ভুল ধরতে সাহায্য করে যা মানুষ শত শত লাইনের রিভিউতে মিস করে:\n\n- কোনো লোকেলে মিসিং কী (ফ্যালব্যাক পরে সমস্যা লুকায়)\n- আনইউজড কী (চিহ্ন যে আপনি ড্রিফট করছেন)\n- প্লেসহোল্ডার মিল না থাকা ('Hello, {name}' বনাম 'Hello, {username}')\n- কোনো লোকেলের জন্য অবৈধ প্লুরাল ফর্ম\n- মোবাইলে রো স্ট্রিং-এ রা HTML থাকার মতো নিষিদ্ধ প্যাটার্ন\n\nতারপর একটি পরিষ্কার ম্যানুয়াল সাইন-অফ লুপ রাখুন। প্রোডাক্ট মেনিং ও টোন যাচাই করবে মূল স্ক্রিনগুলোর জন্য, আর QA লেআউট ও ইন্টারঅ্যাকশন চেক করবে।\n\nটেস্ট ম্যাট্রিক্স ছোট কিন্তু কঠোর রাখুন। সবকিছু টেস্ট করবেন না। আগে ভাঙে এমন জায়গাগুলো টেস্ট করুন: লগইন/সাইনআপ, পাসওয়ার্ড রিসেট, চেকআউট বা পেমেন্ট কনফার্মেশন, সেটিংস ও প্রোফাইল এডিট, নোটিফিকেশন ও এম্পটি স্টেট এবং যে কোনো স্ক্রিনে টেবিল, ব্যাজ বা ছোট বোতাম আছে।\n\nইস্যু রিপোর্ট করলে ফিক্স সহজ করতে স্পষ্ট থাকুন: লোকেল, ডিভাইস ও OS ভার্সন (বা ব্রাউজার ও উইথ), প্রত্যাশিত টেক্সট, প্রকৃত টেক্সট, এবং ক্লিপ হওয়া এর স্ক্রিনশট। যদি এটি প্লুরালাইজেশন বা প্লেসহোল্ডার নিয়ে হয়, সঠিক কী ও রেন্ডার হওয়া স্ট্রিং পেস্ট করুন।\n\n## সাধারণ ভুল ও তা কিভাবে এড়াবেন\n\nবেশিরভাগ লোকালাইজেশন বাগ 'অনুবাদ সমস্যা' নয়। এগুলো ওয়ার্কফ্লো সমস্যা যা ভাঙা UI, মিসিং টেক্সট বা বিভ্রান্তিকর মেসেজ হিসেবে দেখা দেয়।\n\nএকটি সাধারণ ফাঁদ হল কী-র নাম পরিবর্তন করা যখন আপনি শুধুই কপি বদলাতে চান। কীগুলো স্থিতিশীল আইডি হওয়া উচিত, টেক্সট নিজে নয়। যদি আপনি checkout.button.pay থেকে checkout.button.pay_now পরিবর্তন করেন, সব পুরনো অনুবাদ 'মিসিং' হয়ে যাবে এবং ইতিহাস হারাবেন। কী রাখুন, বেস-ভাষার স্ট্রিং আপডেট করুন, এবং যদি অর্থ বদলে যায় তবে কনটেক্সট যোগ করুন।\n\nআরেকটি ঘনঘন সমস্যা হল এক প্ল্যাটফর্মে স্ট্রিং হার্ডকোড করা। ওয়েব দল কী ব্যবহার করে কিন্তু মোবাইল টিম দ্রুত সমাধানে লিটারাল টেক্সট সোজা ঢুকিয়ে দেয়। এক মাস পরে iOS-এ ইংরেজি-এলার্ট দেখা যায়। 'কোনও প্ল্যাটফর্মে ইউজার-ফেসিং স্ট্রিং হার্ডকোড করা হবে না' একটি শেয়ার্ড নিয়ম করে নিন।\n\nপ্লেসহোল্ডারগুলো সাবধানে ব্যবহার করুন—শব্দের ক্রম ধরে নেওয়া সূক্ষ্ম ত্রুটি ঘটায়। ইংরেজিতে '{count} items' কাজ করে, কিন্তু অন্যান্য ভাষায় অন্য ক্রম বা অতিরিক্ত শব্দ দরকার হতে পারে। নামকৃত প্লেসহোল্ডার ব্যবহার করুন এবং প্ল্যাটফর্ম জুড়ে একরূপ রাখুন।\n\nশুরুতেই ধরার মতো ভুলগুলো:\n\n- কীগুলোকে কপি হিসেবে ট্রিট করা, পরে বিদ্যমান অনুবাদ ভেঙে ফেলা। কীগুলো স্থিতিশীল রাখুন।\n- এক কী দুটো ভিন্ন অর্থে ব্যবহার করা। যদি অভিপ্রায় আলাদা হয় তবে কী আলাদা রাখুন।\n- প্লেসহোল্ডার শৈলী মিশানো (কিছু নামকৃত, কিছু নম্বর) — একটা স্ট্যান্ডার্ড ঠিক করুন।\n- কেবল ইংরেজিতে টেস্ট করা। সর্বদা কমপক্ষে একটি লম্বা-টেক্সট লোকেল ও একটি কমপ্যাক্ট লোকেল চেক করুন।\n- কোনো ফেলব্যাক প্ল্যান ছাড়া শিপ করা। রিলিজের আগে ঠিক কি হবে তা নির্ধারণ করুন।\n\nশুধু একটি 'লম্বা ভাষা' টেস্ট করা যথেষ্ট নয়। জার্মান প্রায়শই UI বাড়ায়, আর চীনা স্পেসিং সমস্যা ঢেকে রাখে। দুটোতে দ্রুত পাস করুন, এবং প্লুরাল এজ-কেস যেমন 0, 1, 2 টেস্ট করুন।\n\nরিলিজের আগে ফেলব্যাক আচরণ সম্মত হন। উদাহরণ: যদি ফরাসি মিসিং, তাহলে ইংরেজিতে ফেলব্যাক করুন, মিসিং কী লগ করুন, এবং শুধুমাত্র ক্রিটিক্যাল স্ক্রিন ফাঁক থাকলে রিলিজ ব্লক করুন।\n\n## দ্রুত চেকলিস্ট এবং কার্যকর পরবর্তী ধাপ\n\nএকটি লোকালাইজেশন ওয়ার্কফ্লো তখনই স্বাস্থ্যকর থাকে যখন চেকগুলো ছোট ও পুনরাবৃত্তিযোগ্য। লক্ষ্য সরল: কম অবাঞ্ছিত স্ট্রিং, কম ভাঙা লেআউট, কম শেষ মুহূর্তের অনুবাদ তাড়াহুড়ো।\n\nএকটি UI পরিবর্তন মার্জ করার আগে দ্রুত নিম্নলিখিত 'উপেক্ষ্য করা' বিষয়গুলো দেখুন:\n\n- নতুন কী আপনার নামকরণ নিয়ম মেনে চলছে এবং সঠিক নেমস্পেসে আছে (স্ক্রিন বা ফিচার)\n- প্লেসহোল্ডার প্রতিটি ভাষায় একসাথে মেলে (একই ভেরিয়েবল, একই অর্থ)\n- বিভিন্ন ভাষার জন্য বহুবচন ফর্ম সম্পূর্ণ (শুধু ইংরেজির একক/বহুবচন নয়)\n- UI-তে আর কোনো হার্ডকোডেড টেক্সট নেই (এরর স্টেট ও এম্পটি স্টেট সহ)\n- নতুন বা পরিবর্তিত টেক্সটের জন্য মৌলিক কনটেক্সট আছে (স্ক্রিনশট বা পরিষ্কার নোট)\n\nশিপ করার আগে একটি সংক্ষিপ্ত রিলিজ QA চালান যা লোকালাইজেশন প্রথমে ভাঙে এমন জায়গায় ফোকাস করে। সময়-সীমাবদ্ধ রাখুন, কিন্তু ধারাবাহিক: প্রতিটি প্ল্যাটফর্মে প্রধান ইউজার ফ্লো, এক RTL স্পট চেক, লম্বা-টেক্সট স্ক্রিন (সেটিংস, লিগ্যাল, অনবোর্ডিং, টেবিল, সংকীর্ণ বোতাম), এবং কয়েকটি লোকেলে তারিখ/নম্বর/মুদ্রা ফরম্যাটিং চেক করুন।\n\nআপনার টিমের সাথে মিল রেখে ক্যাডেন্স সেট করুন। অনেক টিম সাপ্তাহিক অনুবাদ আপডেট করে, তারপর রিলিজের 1–2 দিন আগে স্ট্রিং ফ্রিজ করে। উদ্দেশ্য হচ্ছে শেষ মুহূর্তের কপি সম্পাদন ও ফাইনাল QA একসাথে না হওয়া।\n\nতারকীয় পরবর্তী ধাপ যা দ্রুত ফল দেয়: আপনার কনভেনশনগুলো লিখে রাখুন (কী নামকরণ, প্লেসহোল্ডার, প্লুরাল নিয়ম, মালিকানা), তারপর একটি পাইলট স্ক্রিন end-to-end চালান এবং ভাঙে কী দেখে সেই অনুযায়ী সামঞ্জস্য করুন।\n\nযদি আপনি ব্যাকএন্ড, ওয়েব UI এবং নেটিভ মোবাইল এক প্ল্যাটফর্মে যেমন AppMaster নিয়ে কাজ করে থাকেন, কী ও প্লেসহোল্ডার স্থিতিশীল রাখা সহজ হয় কারণ একই স্ক্রিন ও লজিক একটি কনভেনশন শেয়ার করতে পারে। ঐ কনভেনশনকে স্থিতিশীল রাখাই লোকালাইজেশনকে ভঙ্গুর না করে রুটিনের মতো করে তোলে।