Respondo বানানো হয়েছিল দুবাইয়ে, আর সেই তথ্যটাই আমাদের নেওয়া যেকোনো রোডম্যাপ-সিদ্ধান্তের চেয়ে বেশি পণ্যটিকে গড়ে দিয়েছে। এখানে একটিমাত্র সাপোর্ট কিউতে থাকতে পারে একজন গ্রাহক যিনি আরবিতে লিখছেন, আরেকজন ইংরেজিতে, তৃতীয় একজন হিন্দিতে, আর চতুর্থ একজন উর্দুতে — প্রায়ই একই ঘণ্টার মধ্যে। এই পণ্যের এমন কোনো সংস্করণ কখনও ছিল না, যা একটি ভাষাকে ডিফল্ট আর বাকিগুলোকে অনুবাদ হিসেবে ধরত। ত্রিশের বেশি ভাষা, ডান-থেকে-বাঁ ভাষাসহ, হতে হয়েছিল ভিত্তি, পরে যোগ করা একটা স্তর নয়।
সেই বাধ্যবাধকতাটাই শেষমেশ স্পষ্টতা এনে দিল। বহুভাষিকতা যখন ঐচ্ছিক নয়, তখন ইংরেজি-প্রথম একটা পণ্যে যেসব শর্টকাট যুক্তিসঙ্গত মনে হয়, তার অনেকগুলোই নিজেদের অন্ধ গলি হিসেবে প্রকাশ করে ফেলে। AI আর ইন্টারফেস দুই জায়গাতেই সেই বাস্তবতার জন্য বানাতে গিয়ে আমরা যা শিখেছি, তা এখানে।
অনুবাদ মানে বোঝা নয়
লোভনীয় স্থাপত্যটা হলো একটা পাইপলাইন: আসা বার্তাটা নাও, একটা অনুবাদ API দিয়ে সেটাকে ইংরেজিতে চালাও, তোমার ইংরেজি মডেল দিয়ে প্রসেস করো, একটা ইংরেজি জবাব তৈরি করো, সেটা আবার অনুবাদ করে ফেরত দাও। এটা সস্তা, বানাতে দ্রুত, আর ঠিক সেই পরিস্থিতিগুলোতেই ব্যর্থ হয় যা দিয়ে গ্রাহকসেবা গড়া।
গ্রাহকের কথোপকথন এমন প্রেক্ষাপটে ঠাসা, যা সাধারণ অনুবাদ চ্যাপ্টা করে দেয়। অপভাষা, বাগধারা, বিনয়ের স্তর আর নির্দিষ্ট ক্ষেত্রের পরিভাষা — যাওয়া-আসার পথে সবই ঘষে ক্ষইয়ে যায়। ক্লাসিক উদাহরণটা হলো একটা শব্দ যার অর্থে শাখা আছে: খুচরা প্রেক্ষাপটে একজন গ্রাহকের "return" নিয়ে প্রশ্ন মানে একটা পণ্য ফেরত পাঠানো; একই শব্দ আর্থিক প্রেক্ষাপটে বিনিয়োগের মুনাফা নিয়ে। অনুবাদ-প্রসেস-অনুবাদ সুতোটা হারিয়ে ফেলে, কারণ ইংরেজি মডেল যতক্ষণে সেটা দেখে, ততক্ষণে অর্থ-স্পষ্টকারী প্রেক্ষাপটটা ইতিমধ্যেই দুমড়ে গেছে।
Respondo বদলে ভাষা-নির্দিষ্ট মডেল ব্যবহার করে। আরবিতে একটা বার্তা বোঝা আর জবাব দেওয়া হয় আরবিতেই, স্বভাবজাতভাবে, মধ্যবর্তী উপস্থাপনা হিসেবে ইংরেজির ভেতর দিয়ে না গিয়ে। যে পার্থক্যগুলো গুরুত্বপূর্ণ — সুর, স্তর, একটা দ্ব্যর্থক শব্দের ঠিক অর্থ — সেগুলো ধরা পড়ে ঠিক সেই ভাষাতেই যেখানে সেগুলো আসলে বাস করে। একটা কারিগরিভাবে সঠিক জবাব আর একটা জবাব যা কোনো নেটিভ বক্তা সাবলীল বলে চিনে নেন, এই দুইয়ের তফাত সেটাই।
ইন্টারফেস যখন উল্টে যায়
মডেলে ভাষাগুলো সামলানো অর্ধেক সমস্যা। বাকি অর্ধেকটা হলো ইন্টারফেস, আর ডান-থেকে-বাঁ ভাষাগুলোই সেই জায়গা যেখানে বেশিরভাগ ডিজাইন সিস্টেম নীরবে ভেঙে পড়ে।
আরবি আর হিব্রু সমর্থন করা মানে স্ট্রিং অনুবাদ করার ব্যাপার নয়। গোটা লেআউটটাই উল্টে যায়। টেক্সট ডানে সারিবদ্ধ হয়। পড়ার ক্রম চলে ডান থেকে বাঁয়ে, অর্থাৎ একটা কথোপকথনের দৃশ্যমান প্রবাহ, একটা back বোতামের অবস্থান, একটা তির কোন দিকে দেখাবে — সবই আয়নার প্রতিবিম্ব হয়ে যায়। স্থির অবস্থানে বাঁ-থেকে-ডান ধারণা গেঁথে বানানো একটা ডিজাইন RTL-এ অনূদিত হয় না; ভেঙে পড়ে।
সূক্ষ্ম ব্যাপারটা হলো সবকিছু উল্টায় না। এটাই সেই ফাঁদ যাতে টিমগুলো পড়ে যখন তারা CSS-এর direction প্রপার্টি আবিষ্কার করে ভাবে কাজ শেষ।
- লেআউট, টেক্সটের সারিবদ্ধকরণ আর পড়ার ক্রম আয়নায় উল্টায়। ইংরেজিতে বাঁয়ে থাকা একটা সাইডবার আরবিতে ডানে থাকার কথা।
- দিকনির্দেশক আইকন উল্টানোটা উত্তরাধিকারে পায়। একটা "reply" তির বা একটা "next" শেভরনকে উল্টো দিকে দেখাতে হয়, কারণ তার অর্থটাই দিকনির্দেশক।
- যে কনটেন্ট স্বভাবতই LTR তা উল্টায় না। ফোন নম্বর, ল্যাটিন-লিপির ব্র্যান্ড নাম, কোড স্নিপেট আর URL চারপাশের ভাষা যাই হোক পড়া হয় বাঁ থেকে ডানে। সেগুলো উল্টে দিলে আপনি অর্থহীনতা তৈরি করলেন।
এটা হাতে হাতে, কম্পোনেন্ট ধরে ধরে, গোটা একটা পণ্য জুড়ে ঠিক করা — এটা ঠিক সেই ধরনের কাজ, যা পণ্য বাড়ার সঙ্গে সঙ্গে সঙ্গতিপূর্ণ রাখা অসম্ভব। তাই আমরা এটা হাতে করিনি।
অবস্থান-ভিত্তিক নয়, বাধ্যবাধকতা-ভিত্তিক
যে সিদ্ধান্তটি RTL-কে টেকসই করল, তা হলো আমাদের কম্পোনেন্টগুলোকে পরম অবস্থানের ভাষায় বর্ণনা করা বন্ধ করে সম্পর্কের ভাষায় বর্ণনা করা শুরু করা।
একটা অবস্থান-ভিত্তিক কম্পোনেন্ট বলে "এই লেবেলটা বাঁ প্রান্ত থেকে ১৬ পিক্সেল দূরে বসে।" লেআউট উল্টে যাওয়ার মুহূর্তেই সেই নির্দেশটা ভুল। একটা বাধ্যবাধকতা-ভিত্তিক কম্পোনেন্ট বলে "এই লেবেলটা সারির শুরুতে বসে, কনটেন্ট শুরু হওয়ার আগে ১৬ পিক্সেল ফাঁক রেখে।" এখন "শুরু" স্বয়ংক্রিয়ভাবে ইংরেজিতে বাঁ আর আরবিতে ডানে গিয়ে দাঁড়ায়, আর একটিও শর্তসাপেক্ষ ছাড়াই একই কম্পোনেন্ট সংজ্ঞা দুই দিকেই সঠিকভাবে রেন্ডার হয়।
এটা প্রকাশ করতে আমরা ভরসা করেছি ব্রাউজারের নিজস্ব লজিক্যাল প্রপার্টির উপর — সেই আধুনিক CSS, যা *left* আর *right*-এর বদলে ভাবে *start* আর *end*-এ, আর অনুভূমিক ও উল্লম্বের বদলে *inline* আর *block*-এ। এভাবে লেখা একটা কম্পোনেন্ট জানে না বা পরোয়া করে না সে কোন দিকে রেন্ডার হচ্ছে। দিকটা একবারই ঠিক করা হয়, মূলে, আর তার নিচের প্রতিটি কম্পোনেন্ট নিজেকে মানিয়ে নেয়।
লাভটা চক্রবৃদ্ধি হারে বাড়ে। পরবর্তী RTL ভাষা যোগ করতে খরচ প্রায় শূন্য, কারণ লেআউট-যুক্তি গোড়া থেকেই কোনো নির্দিষ্ট দিকের সঙ্গে বাঁধা ছিল না। ভাগ করা মৌলিক উপাদানের উপর গড়া একটা নতুন কম্পোনেন্ট ডিফল্টেই দুই দিকে সঠিক — একজন ইঞ্জিনিয়ারকে সেটা ভাঙতে হলে পথের বাইরে গিয়ে চেষ্টা করতে হবে।
টেক্সটের নিঃশ্বাস নেওয়ার জায়গা
শেষ শিক্ষাটা সবচেয়ে কম চমকপ্রদ আর সবচেয়ে বেশিবার উপেক্ষিত: টেক্সটের দৈর্ঘ্য ভাষায় ভাষায় বিপুলভাবে বদলায়, আর যে লেআউট কেবল ইংরেজিই দেখেছে সেটা এমন ভাষার নিচে ফাটবে যেগুলো আঁটে না।
একই বাক্যাংশ জার্মানে ৩০% লম্বা হতে পারে, চীনায় একেবারে ভিন্ন একটা অক্ষরসেটে পৌঁছাতে পারে যেখানে কয়েকটা অক্ষর সেটা বহন করে যার জন্য ইংরেজির একটা আস্ত বাক্য লাগে, কিংবা আরবি লিপির উপরে-নিচে বসা ডায়াক্রিটিকের জন্য বেশি উল্লম্ব জায়গা দরকার হতে পারে। ইংরেজি শব্দ "Send"-এর মাপে বানানো একটা বোতাম একটা লম্বা অনুবাদ তাতে পড়ার মুহূর্তেই কেটে যায় বা উপচে পড়ে।
আমাদের কম্পোনেন্টগুলো গোড়া থেকেই ধরে নেয় যে তাদের টেক্সট কত লম্বা হবে তারা জানে না। সেগুলো তাদের কনটেন্টের সঙ্গে বাড়ে, সুন্দরভাবে মুড়ে যায়, আর কখনও একটা স্ট্রিং নির্দিষ্ট দৈর্ঘ্যের হওয়ার উপর নির্ভর করে না। এটা একটা ছোট নিয়মানুবর্তিতা, যা পরে হাজারটা এককালীন লেআউট-সংশোধন বাঁচায় — আর, দিক সামলানোর মতোই, এটা এমন একটা জিনিস যা প্রথম দিন থেকে গড়ে নিলে প্রায় বিনামূল্যে আর পরে জুড়তে গেলে বিপুল ব্যয়বহুল।
সংযোগসূত্র
এই প্রতিটি সিদ্ধান্তই একই ভাবনার সঙ্গে মিলে যায়: বহুভাষিকতা এমন একটা বৈশিষ্ট্য হতে পারে না যা আপনি যোগ করেন, কারণ একটি একক-ভাষা পণ্যের ধারণাগুলো মডেল, লেআউট আর প্রতিটি কম্পোনেন্টের ভেতরে হাত বাড়ায়। ইংরেজি-প্রথম বানান, আর পণ্যের বাকি জীবন কাটাবেন সেসব জায়গা তালি দিয়ে যেখানে ওই ধারণাগুলো চুইয়ে পড়ে। গোড়া থেকে ত্রিশটা ভাষার জন্য বানান, আর একত্রিশতমটা প্রায় বিনামূল্যে। যেখানে আমাদের গ্রাহকরা দিনে ডজনখানেক ভাষা বলেন সেখানে ভিত্তি গড়া এটাকে কঠিনতর করেনি — এটা নীরবে ভুল করাকে অসম্ভব করে দিয়েছে, আর সেটাই সেরা ধরনের বাধ্যবাধকতা যার নিচে ডিজাইন করা যায়।
