Vue 3 i18n ওয়ার্কফ্লো 500+ কী-এ — প্রডাকশনে চমক ছাড়া

500+ i18n কী-এ সাধারণত কী ভুল হয়

আপনার অ্যাপে কয়েকশটা স্ট্রিং পেরোলেই প্রথম ভাঙা জিনিস সাধারণত Vue I18n নয়—এটা স্থিরতা (consistency)। মানুষ বিভিন্ন স্টাইলে কী যোগ করে, একই ধারনাকে বিভিন্ন নামে ডুপ্লিকেট করে, এবং আর কেউ নিশ্চিত থাকে না কোন মেসেজগুলো মুছলে নিরাপদ।

অনুপস্থিত অনুবাদও আর বিরল থাকে না। সাধারণ ইউজার পাথগুলোতেই দেখা দেয়, বিশেষ করে কম ব্যবহৃত স্ক্রিনগুলোতে—সেটিংস, এরর স্টেট, খালি স্টেট, এবং নোটিফিকেশনগুলিতে।

যখন কোনো অনুবাদ নেই, ব্যবহারকারী সাধারণত তিন রকম ফলাফল দেখে: খালি UI (বাটনে লেবেল নেই), কাঁচা কী দেখা যায় (যেমন checkout.pay_now), কিংবা পেজের কোনো অংশ হঠাৎ অন্য ভাষায় চলে যায়। এগুলো কোনো ছোট বাগ মনে করায় না—এগুলো অ্যাপটাকে ভাঙা দেখায়।

এই জন্য Vue 3 i18n ওয়ার্কফ্লো লাইব্রেরির চেয়ে বেশি গুরুত্বপূর্ণ। লাইব্রেরি আপনি যা বলবেন তাই করবে; কিন্তু বড় আকারে টিমরা প্রায়ই একমত হয় না যে “কাজ শেষ” হলে কী হবে।

একটি প্রচলিত উদাহরণ: একজন ডেভেলপার নতুন "Invite teammate" ফ্লো পাঠায় ৪০টা স্ট্রিং নিয়ে। ইংরেজি ফাইল আপডেট হয়, কিন্তু ফরাসি ফাইল হয় না। স্টেজিং-এ সব ঠিক দেখায় কারণ টেস্টার ইংরেজি ব্যবহার করে। প্রডাকশনে ফরাসি ব্যবহারকারীরা মিশ্র অনুবাদ ও অনুবাদহীন UI দেখেন, এবং সাপোর্টে কাঁচা কী-র স্ক্রিনশট আসে।

সমাধান হলো অনুবাদিত UI-এর জন্য "কাজ সম্পন্ন" কী মানে তা সংজ্ঞায়িত করা। এটি শুধু "স্ট্রিং যোগ হয়েছে" হওয়া যাবে না। একটি ব্যবহারিক ডেফিনিশন সাধারণত অন্তর্ভুক্ত করে: কী গুলো নামকরণ নিয়ম অনুসরণ করে, locales বিল্ড হয় মিসিং-কী সতর্কতা ছাড়াই, plurals ও ভ্যারিয়েবলগুলো বাস্তব ডেটা দিয়ে সঠিক রেন্ডার হয়, অন্তত একটি নন-ডিফল্ট লোকেল যাচাই করা হয়েছে, এবং কপি পরিবর্তন ট্র্যাক করা হচ্ছে যাতে পুরনো কীগুলি ভাসমান না থাকে।

500+ কী-এ জয় পেতে Localization-কে একটা রিলিজ প্রক্রিয়া হিসেবে নেওয়া বুদ্ধিমানের কাজ, না যে শেষ মুহূর্তে শুধু ফাইল এডিট করা হবে।

আরও স্ট্রিং যোগ করার আগে কয়েকটি নিয়ম ঠিক করুন

কয়েকশটি স্ট্রিং পেরোলেই অনুবাদ কাজ আর গোলমেলে অংশ নয়—কনসিস্টেন্সি হয় মূল চ্যালেঞ্জ। ছোট একটা নিয়ম সেট আপনার Vue 3 i18n ওয়ার্কফ্লো-কে প্রেডিক্টেবল করে, এমনকি যখন প্রতি সপ্তাহে একাধিক লোক কপি ছুঁয়ে।

শুরু করুন "কনসেপ্ট" কি তা নির্ধারণ করে এবং তার জন্য একটি একক সত্য উৎস রাখুন। একই UI ধারনা যদি পাঁচ জায়গায় আসে (উদাহরণস্বরূপ, “Save changes”), আপনি একটাই কী চান, পাঁচটা ভ্যারিয়েন্ট না (save, saveChanges, save_update, saveBtn)। ডুপ্লিকেট কীগুলো সময়ের সাথে অর্থে ভাসমান হয়ে পড়ে, এবং ব্যবহারকারী সেই অসঙ্গতি অনুভব করে।

পরের ধাপ—ফরম্যাটিং কোথায় থাকবে নির্ধারণ করা। টিমগুলো সাধারণত ভুলবশত এটাকে বিভক্ত করে: কিছু মেসেজে পাংচুয়েশন ও কেসিং থাকে, অন্যগুলো কোডে আশা করে। একটি পদ্ধতি বেছে নিন এবং সেটি মেনে চলুন।

একটি ব্যবহারিক ডিফল্ট:

• ব্যাকরণ, পাংচুয়েশন, এবং ব্যবহারকারীর সামনে দেখা ফরম্যাটিং (যেমন “(optional)”) মেসেজের মধ্যে রাখুন।
• খাঁটি ডেটা ফরম্যাটিং কোডে রাখুন (তারিখ, কারেন্সি, ইউনিট), এবং ফলাফলটি i18n-এ পাস করুন।
• নাম ও কাউন্টের জন্য প্লেসহোল্ডার ব্যবহার করুন, স্ট্রিং কনক্যাটিনেশন নয়।
• মেসেজে HTML ব্যবহারকে বিশেষ কেস হিসেবে বিবেচনা করুন এবং স্পষ্ট নিয়ম রাখুন (অনুমোদিত না হলে না করা ভাল)।

তারপর Ownership সংজ্ঞায়িত করুন। কে নতুন কী যোগ করতে পারবে, কে বেস-ল্যাঙ্গুয়েজ কপি রিভিউ করবে, এবং কে অন্যান্য লোকেল অনুমোদন করবে—এরকম সিদ্ধান্ত নিন। না হলে স্ট্রিংগুলো তাড়াহুড়োয় যোগ হবে এবং কখনো রিভিউ হবে না।

অবশেষে, একটি ফলব্যাক স্ট্র্যাটেজি ডকুমেন্ট করুন। যদি কোনো কী মিস হয়, ব্যবহারকারী কী দেখবে: কী নাম, ডিফল্ট-লোকেল টেক্সট, না কি একটা নিরাপদ জেনেরিক মেসেজ? প্রডাকশনে অনেক টিম পছন্দ করে ডিফল্ট লোকেলে ফলব্যাক করা ও লগ করা, যাতে ব্যবহারকারী ব্লক না হয় আর আপনিও সিগন্যাল পান যে কিছু ভুল আছে।

আপনি যদি AppMaster (Vue3 web UI plus real backend code)–এর মতো জেনারেটর দিয়ে Vue 3 অ্যাপ তৈরি করেন, এই নিয়মগুলো তবু প্রযোজ্য। ট্রান্সলেশনকে "শুধু ডেভ টেক্সট" হিসেবে না দেখে প্রোডাক্ট কন্টেন্ট হিসেবে বিবেচনা করুন—এতে বেশিরভাগ শেষ মুহূর্তের চমক আপনি এড়িয়ে যাবেন।

পড়তে সহজ রাখার জন্য কী নামকরণ কনভেনশন

কয়েকশটা স্ট্রিং পেরোলেই কনসিস্টেন্সি সবচেয়ে বড় গুণবৃদ্ধি। একটাই কী স্টাইল বেছে নিন (অধিকাংশ টিম ডট পাথ ব্যবহার করে যেমন billing.invoice.title) এবং এটাকেই নিয়ম বানিয়ে দিন। ডট, স্ল্যাশ, snake_case, ও র্যান্ডম কেস মিশ্রিত করলে সার্চ ও রিভিউ ধীর করে।

কপির পরিবর্তন টিকে টিকে থাকা স্টেবল কীগুলো ব্যবহার করুন। "Please enter your email" টাইপের কী কপির সামান্য পরিবর্তনে ভেঙে পড়বে। উদ্দেশ্য-ভিত্তিক নাম দিন যেমন auth.email.required বা auth.email.invalid।

প্রোডাক্ট এরিয়া বা UI সারফেস অনুযায়ী প্রথমে গ্রুপ করুন, তারপর উদ্দেশ্য অনুযায়ী। আপনার অ্যাপের একই বালতিতে ভাবুন: auth, billing, settings, support, dashboard। এতে লোকেল ফাইলগুলো স্ক্যান করা সহজ হয় এবং ডুপ্লিকেট কম হয় যখন দুইটা স্ক্রিন একই ধারনা চাই।

প্রতিটি এরিয়ার মধ্যে সাধারণ UI পিসগুলোর জন্য ছোট প্যাটার্ন রাখুন:

• Buttons: *.actions.save, *.actions.cancel
• Labels: *.fields.email.label, *.fields.password.label
• Hints/help text: *.fields.email.hint
• Errors/validation: *.errors.required, *.errors.invalidFormat
• Notifications/toasts: *.notices.saved, *.notices.failed

ডায়নামিক মেসেজগুলিতে কী পরিবর্তন হবে সেটা বলুন, কিভাবে নয়। মেসেজকে উদ্দেশ্য হিসেবে নাম দিন এবং পরিবর্তনশীল অংশগুলোর জন্য প্যারামিটার ব্যবহার করুন। উদাহরণস্বরূপ, {days} সহ billing.invoice.dueInDays billing.invoice.dueIn3Days-এর চেয়ে পরিষ্কার।

উদাহরণ (Vue 3 i18n ওয়ার্কফ্লো-তে ভালো কাজ করে): orders.summary.itemsCount যেখানে {count} দিয়ে সংখ্যাটি পাঠান, আর orders.summary.total যেখানে {amount} দিয়ে টাকা দেখান। কোডে কেউ কী পড়লে জানবে এটা কোথায় লাগে ও কেন আছে, এমনকি যদি ফাইনাল কপি পরে বদলে যায়।

বহুবচন নিয়ম ও মেসেজ ফরম্যাটিং যাতে চমক না থাকে

আপনি যদি প্রত্যেক ভাষাকে ইংরেজির মতো ধরেন, plurals চুপিচুপি ভাঙে। শুরুর দিকে ঠিক করে নিন কখন ICU মেসেজ সিনট্যাক্স ব্যবহার করবেন এবং কখন সাধারণ প্লেসহোল্ডার যথেষ্ট।

লেবেল ও ছোট UI টেক্সটের জন্য সরল রিপ্লেসমেন্ট ব্যবহার করুন যা সংখ্যার উপর নির্ভর করে না (উদাহরণ: "Welcome, {name}")। গণনা-ভিত্তিক যেকোনো জিনিসের জন্য ICU ব্যবহার করুন, কারণ এতে সব ফর্ম এক জায়গায় থাকে এবং নিয়মগুলো স্পষ্ট হয়।

{
  "notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}

কাউন্ট মেসেজগুলো এমনভাবে লিখুন যাতে অনুবাদ করা সহজ হয়। পুরো বাক্য পছন্দ করুন এবং সংখ্যার প্লেসহোল্ডার (#) নামের কাছে রাখুন। কোডে একই কী reuse করে "1 item" ও "2 items" তৈরি করার মত চতুর শর্টকাট এড়িয়ে চলুন—অনুবাদকরা পুরো মেসেজ দেখতে চায়, কিভাবে রেডি করা হবে তা আন্দাজ করতে নয়।

হাতে-কলমে =0, one, এবং other অন্তত রাখুন, এবং 0-এর জন্য আপনি কী প্রত্যাশা করেন তা ডকুমেন্ট করুন। কিছু প্রোডাক্ট “0 items” চান, অন্যরা “No items” চান। একটি স্টাইল বেছে নিন এবং সেটি মেনে চলুন যাতে UI কনসিস্টেন্ট লাগে।

আরও লক্ষ্য রাখুন—কয়েক ভাষায় আপনার প্রত্যাশার চেয়ে বেশি প্লুরাল ক্যাটাগরি থাকে। অনেক ভাষা “one vs many” অনুসরণ করে না। যদি পরে নতুন লোকেল যোগ করেন, শুধুমাত্র one ও other থাকা মেসেজটি ব্যাকরণগতভাবে ভুল হতে পারে, এমনকি যদি রেন্ডার হয়।

শিপ করার আগে UI-তে বাস্তব কাউন্ট নিয়ে প্লুরালগুলো টেস্ট করুন, শুধুমাত্র JSON দেখে নয়। দ্রুত চেক হিসেবে 0, 1, 2, 5, ও 21 ব্যবহার করলে বেশিরভাগ সমস্যা ধরা পড়ে।

আপনি যদি Vue3 ওয়েব অ্যাপ তৈরি করেন (উদাহরণস্বরূপ AppMaster-এর সাথে), এই টেস্টটি সেই একচুয়াল স্ক্রিনে করুন যেখানে টেক্সটটি দেখা যায়। লেআউট সমস্যাগুলো, কাটঅফ টেক্সট, এবং অদ্ভুত বাক্যগঠন প্রথমে সেখানে দেখা দেয়।

বৃদ্ধি সক্ষম করে লোকেল ফাইলগুলো সংগঠিত করা

কয়েকশটা স্ট্রিং পড়ার পর একটি বড় en.json বোতল গল হয়ে যায়। একই ফাইল একাধিক মানুষ স্পর্শ করলে মিশ.merge কনফ্লিক্ট বাড়ে, এবং আপনি কোথায় কপি আছে তা হারান। ভালো স্ট্রাকচার আপনার Vue 3 i18n ওয়ার্কফ্লো-কে স্থিতিশীল রাখে এমনকি প্রোডাক্ট পরিবর্তিত হলেও।

প্রস্তাবিত স্ট্রাকচার

2 থেকে 5 লোকেল পর্যন্ত, ফিচার অনুসারে ভাগ করা যথেষ্ট। প্রতিটি লোকেলে একই ফাইল লেআউট রাখুন যাতে কী যোগ করা পূর্বানুমানযোগ্য।

• locales/en/common.json, locales/en/auth.json, locales/en/billing.json
• locales/es/common.json, locales/es/auth.json, locales/es/billing.json
• locales/index.ts (messages লোড ও মার্জ করে)

20+ লোকেল হলে একই ধারণা স্কেল করুন কিন্তু ড্রিফ্ট কঠিন করুন। English-কে সোর্স অফ ট্রুথ হিসেবে নিন এবং প্রয়োগ করুন যে প্রতিটি লোকেল একই ফোল্ডার ও ফাইল নাম মিরর করবে। যদি একটি নতুন ডোমেইন আসে (উদাহরণ notifications), সেটি প্রতিটি লোকেলের জন্য থাকা উচিত, এমনকি টেক্সট সাময়িক হলেও।

ডোমেইন অনুসারে ভাগ করলে মিশ.merge কনফ্লিক্ট কমে কারণ দুইজন মানুষ আলাদা ফাইলে স্ট্রিং যোগ করলে তারা একে অপরের উপর পদার্পণ করে না। ডোমেইনগুলো আপনার অ্যাপ কীভাবে তৈরি হয়েছে তা মেলে: common, navigation, errors, settings, reports, এবং বড় এলাকাগুলির জন্য ফিচার ফোল্ডার।

কী-গুলো কনসিস্টেন্ট রাখা

প্রতিটি ফাইলে একই কী শেইপ রাখুন: একই নেস্টিং, একই কী নাম, শুধু আলাদা টেক্সট। ভাষা অনুযায়ী “ক্রিয়েটিভ” কী এড়িয়ে চলুন, এমনকি কোনো অভিব্যক্তি অনুবাদ করতে কষ্টকর হলে। যদি ইংরেজিতে billing.invoice.status.paid লাগে, প্রতিটি লোকেলে অবশ্যই সেই একই কী থাকতে হবে।

যেগুলো সত্যিই সারাবিভাগে পুনরাবৃত্তি করে তাদেরই সেন্ট্রালাইজ করুন: বাটন লেবেল, জেনেরিক ভ্যালিডেশন এরর, গ্লোবাল ন্যাভিগেশন। ফিচার-স্পেসিফিক কপি ফিচারের পাশেই রাখুন, এমনকি যদি সেটা রিইউজেবল মনে হয়। “Save” common-এ যাবে; “Save payment method” billing-এ থাকবে।

দীর্ঘ-ফর্ম কন্টেন্ট

লম্বা হেল্প টেক্সট, অনবোর্ডিং স্টেপ, ইমেইল টেমপ্লেট দ্রুত গোলমেলে হয়ে যায়। কয়েকটি নিয়ম সাহায্য করে:

• লং-ফর্ম স্ট্রিং আলাদা ডোমেইনে রাখুন (উদাহরণ help বা onboarding) এবং গভীর নেস্টিং এড়িয়ে চলুন।
• এক লাইনের ব্যাপারে বড় স্ট্রিংয়ের বদলে ছোট প্যারাগ্রাফ পছন্দ করুন, যাতে অনুবাদকরা নিরাপদে কাজ করতে পারে।
• যদি মার্কেটিং বা সাপোর্ট বারবার টেক্সট এডিট করে, সেই মেসেজগুলো ডেডিকেটেড ফাইলে রাখুন যাতে চাঙ্গা অংশগুলো কম বিঘ্নিত হয়।
• ইমেইলের ক্ষেত্রে সাবজেক্ট ও বডি আলাদাভাবে সংরক্ষণ করুন এবং প্লেসহোল্ডারগুলো কনসিস্টেন্ট রাখুন (নাম, তারিখ, অংক)।

এই সেটআপ পরিবর্তনগুলো রিভিউ করা, ক্রমানুবাদ করা, এবং রিলিজের ঠিক আগে অপ্রত্যাশিত গ্যাপ এড়ানো সহজ করে।

স্ট্রিং যোগ ও শিপ করার জন্য ধাপে ধাপে ওয়ার্কফ্লো

একটি স্থিতিশীল Vue 3 i18n ওয়ার্কফ্লো টুল নিয়ে বেশি নয়—বরং প্রতিবার একই ছোট ধাপগুলি পুনরাবৃত্তি করা। নতুন UI টেক্সট কোনো কন্ডিশনে প্রডাকশনে পৌঁছাবে না যদি না কী থাকে, একটি ডিফল্ট মেসেজ থাকে, এবং স্পষ্ট অনুবাদ স্ট্যাটাস থাকে।

শুরুতে কীটি আপনার বেস লোকেলে (প্রায়ই en) যোগ করুন। ডিফল্ট টেক্সট বাস্তব কপির মতো লিখুন, প্লেসহোল্ডার নয়। এতে প্রোডাক্ট ও QA-র জন্য পড়ার মত কিছু থাকবে এবং পরে “রহস্য স্ট্রিং” হওয়া যাবে না।

কীটি কম্পোনেন্টে ব্যবহার করার সময় প্রথম দিন থেকেই প্যারামস ও প্লুরাল লজিক যোগ করুন যাতে অনুবাদকরা মেসেজের পুরো আকার দেখতে পারে।

// simple param
$t('billing.invoiceDue', { date: formattedDate })

// plural
$t('files.selected', count, { count })

যদি অনুবাদ প্রস্তুত না থাকে, কীগুলো ফাঁকা ছেড়ে দেবেন না। অন্যান্য লোকেলে প্লেসহোল্ডার অনুবাদ যোগ করুন বা সেগুলোকে ধারাবাহিকভাবে pending হিসেবে মার্ক করুন (উদাহরণ: মানটি TODO: দিয়ে শুরু করুন)। গুরুত্বপূর্ণ অংশ হল অ্যাপটি প্রেডিক্টেবলভাবে রেন্ডার করা এবং রিভিউয়াররা অসমাপ্ত কপি সহজে খুঁজে পায়।

মার্জ করার আগে দ্রুত অটোমেটেড চেক চালান। সেগুলো বোরিং ও স্ট্রিক্ট রাখুন: লোকেলগুলো জুড়ে মিসিং কী, আনইউজড কী, প্লেসহোল্ডার মিসম্যাচ (যেমন {count}, {date} মিসিং বা ভুল ব্রেস), সমর্থিত ভাষার জন্য অবৈধ প্লুরাল ফর্ম, এবং আকস্মিক ওভাররাইট।

শেষে, কমপক্ষে একটি নন-বেস লোকেলে ছোট একটা UI পাস করুন। লেংথি স্ট্রিংয়ের জন্য জার্মান বা ফরাসি মতো ভাষা বেছে নিন যাতে ওভারফ্লো, কাটা বোতাম এবং অদ্ভুত লাইন ব্রেক ধরা পড়ে। যদি আপনার Vue 3 UI AppMaster-এর মতো কোনো টুল দিয়ে জেনারেট বা মেইনটেইন করা হয়, এই ধাপটি এখনও গুরুত্বপূর্ণ কারণ লেআউট ফিচার বদলে গেলে পরিবর্তিত হয়।

এইগুলোকে যেকোনো ফিচারের জন্য আপনার "ডেফিনিশন অফ ডান" হিসেবে গ্রহণ করুন।

টিমগুলো যে সাধারণ ভুলগুলো বারবার করে

লোকালাইজেশনকেই কষ্টসাধ্য করে তোলার দ্রুততম উপায় হল i18n কী-কে শুধু "স্ট্রিং" মনে করা। কয়েকশটা কী হলে ছোট অভ্যাসগুলো প্রডাকশনে বাগে পরিণত হয়।

কীগুলো যে ভাসে, সংঘর্ষ করে, বা মিথ্যা বলে

টাইপো ও কেসিং ভিন্নতা ক্লাসিক কারণ: একটা জায়গায় checkout.title, অন্য জায়গায় Checkout.title। কোড রিভিউতে ঠিকই মনে হয়, পরে আপনার ফলব্যাক ভাষা চুপচাপ শিপ হয়।

আরেকটি সমস্যা হলো এক কী বিভিন্ন অর্থে পুনরায় ব্যবহার করা। “Open” হতে পারে “Open ticket” সাপোর্ট স্ক্রিনে এবং “Open now” স্টোর পেজে। একই কী reuse করলে অন্য ভাষায় একটি স্ক্রিন ভুল হবে, এবং অনুবাদকরা আন্দাজ করবে।

সহজ নিয়ম: একটি কী = একটি অর্থ। যদি অর্থ বদলে যায়, নতুন কী বানান—even যদি ইংরেজি টেক্সট একই থাকে।

“স্ট্রিং-আকৃতির” ধারণা থেকে লেআউট বাগ

টিমরা প্রায়ই পাংচুয়েশন, স্পেসিং, বা কিছু HTML ট্রান্সলেশনে হার্ডকোড করে। এটা কাজ করে যতক্ষণ না কোনো ভাষায় আলাদা পাংচুয়েশন লাগে, বা আপনার UI মার্কআপ আলাদা রূপে রেন্ডার করে। টেমপ্লেটে মার্কআপ সিদ্ধান্ত রাখুন, এবং মেসেজগুলোকে টেক্সট-ভিত্তিক রাখুন।

মোবাইলেই সমস্যা লুকিয়ে থাকে। ইংরেজিতে ফিট করা লেবেল জার্মানে তিন লাইন বাক্যে ভেঙে পড়তে পারে, বা থাই ভাষায় ওভারফ্লো করতে পারে। যদি আপনি শুধু এক স্ক্রিন সাইজ টেস্ট করেন, তা মিস করবেন।

পুনরাবৃত্তি করে দেখা অপব্যবহারগুলো: ভেরিয়েবল ইন্সার্ট করার সময় ইংরেজি শব্দক্রম ধরে নেওয়া, একাধিক টুকরো যোগ করে মেসেজ বানানো বদলে একটিই মেসেজ ব্যবহার না করা, দীর্ঘ ভ্যালু (প্রোডাক্ট নাম, ঠিকানা, এরর ডিটেইল) টেস্ট না করা, সাইলেন্ট ফলব্যাক এনেবল করে শিপ করা যাতে মিসিং কী ইংরেজিতে "ঠিক" দেখায়, এবং ইংরেজি মান এডিট করে কেবল সেটাই কপি-পেস্ট করা।

আপনি যদি চান Vue 3 i18n ওয়ার্কফ্লো 500+ কী-এ শান্ত থাকে, কী-গুলোকে আপনার API হিসাবে আচরণ করুন: স্থিতিশীল, স্পেসিফিক, এবং টেস্টেড।

অনুবাদ মিস হওয়া আগে ধরার জন্য QA ধাপ

অনুবাদ অনুপস্থিত থাকা সহজে মিস হয় কারণ অ্যাপটি এখনও “চলছে।” শুধু কী-তে ফেলব্যাক করে, ভুল লোকেলে চলে যায়, বা খালি স্ট্রিং দেখায়। ট্রান্সলেশন কাভারেজকে টেস্টের মতো বিবেচনা করুন: আপনি চান দ্রুত ফিডব্যাক আর প্রোডাকশনে যাওয়ার আগে সমস্যা ধরা পড়ুক।

অটোমেটেড চেক (প্রতি PR-এ চালান)

বিল্ড ফেল করে এমন চেক দিয়ে শুরু করুন, না এমন চেক যা শুধু ওয়ার্নিং প্রিন্ট করে যাকে কেউ পড়ে না।

• কোডবেস স্ক্যান করে $t('...') ও t('...') ব্যবহার সনাক্ত করুন, তারপর প্রত্যেক ব্যবহৃত কী বেস লোকেলে আছে কি না যাচাই করুন।
• লোকেলগুলোর কী সেট তুলনা করুন এবং যদি কোনো লোকেল কী মিস করে তাহলে ফেল করুন (বশর্তে ওই কী ছোট, রিভিউ করা এক্সসেপশন তালিকায় আছে না)।
• অরফান কীগুলো ফ্ল্যাগ করুন—লোকেল ফাইলে আছে কিন্তু ব্যবহৃত হচ্ছে না।
• মেসেজ সিনট্যাক্স যাচাই করুন (প্লেসহোল্ডার, ICU/প্লুরাল ব্লক)। একটি ভাঙা মেসেজ রuntime-এ পেজ ক্র্যাশ করাতে পারে।
• ডুপ্লিকেট কী বা অসামঞ্জস্য কেসিংকে এরর হিসেবে বিবেচনা করুন।

এক্সসেপশন তালিকা ছোট রাখুন এবং টিমের মালিকানায় রাখুন—"যেটা CI পাস করায় সেটা থাকলে চলবে" ধাঁচে না।

রUNTIME ও ভিজ্যুয়াল চেক (স্টেজিং)

CI থাকলেও স্টেজিং-এ একটি নেট রাখা ভাল কারণ প্রকৃত ইউজার পাথগুলো এমন স্ট্রিং ট্রিগার করে যা আপনি ভুলে গেছেন।

স্টেজিং-এ missing-translation লগিং চালু করুন এবং দ্রুত ফিক্স করার জন্য যথেষ্ট কনটেক্সট দিন: লোকেল, রুট, কম্পোনেন্ট নাম (যদি পাওয়া যায়), এবং মিসিং কী। এটাকে জোরালো করুন—যদি সহজে উপেক্ষা করা যায়, তা উপেক্ষিত হবে।

একটি পসুডো-লোকেল যোগ করুন এবং দ্রুত UI পাসে ব্যবহার করুন। সহজ একটি পদ্ধতি হলো প্রতিটি স্ট্রিং ট্রান্সফর্ম করা (লম্বা করে ও মার্কার যোগ করা) যাতে লেআউট সমস্যাগুলো চোখে পড়ে, উদাহরণ: [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲𝗱 !!!]। এটা কাটো বোতাম, ভাঙা টেবিল হেডার, এবং স্পেসিং সমস্যা ধরায়।

অবশেষে, রিলিজের আগে ২–৩ লোকেলে আপনার সর্বোচ্চ-ভ্যালু প্রবাহগুলোর সংক্ষিপ্ত স্পট চেক করুন: সাইন-ইন, চেকআউট/পেমেন্ট, কোর সেটিংস, এবং আপনি যে নতুন ফিচার রিলিজ করছেন। এখানেই ধরা পড়ে "অনুবাদ করা আছে কিন্তু প্লেসহোল্ডার ভুল" বাগ।

নতুন ভাষা যোগ করা ও ক্রমাগত কপি পরিবর্তন হ্যান্ডেল করা

নতুন ভাষা যোগ করা তখনই গোলমেলে হয় যখন আপনি এটাকে "কপি কাজ" হিসেবে বিবেচনা করেন না যে এটা আসলে একটি ছোট প্রোডাক্ট রিলিজ। আপনার Vue 3 i18n ওয়ার্কফ্লো স্থিতিশীল রাখতে সহজ উপায় হলো অ্যাপটি এমনভাবে বানানো যাতে incomplete লোকেল থাকলেও বিল্ড হয়, তবে ব্যবহারকারীরা দেখার আগে গ্যাপগুলো স্পষ্ট করে তোলা যায়।

নতুন লোকেল যোগ করার সময়, সোর্স লোকেল (প্রায়ই en) থেকে একই ফাইল শেপ জেনারেট করে শুরু করুন। আগে অনুবাদ নয়, স্ট্রাকচার করুন।

• সোর্স থেকে ফুল কী সেট কপি করে নতুন লোকেল ফোল্ডার/ফাইল তৈরি করুন।
• ভ্যালুগুলো TODO প্লেসহোল্ডার হিসেবে মার্ক করুন যাতে QA-তে মিসিং স্ট্রিংগুলো দেখা যায়।
• ভাষা সুইচারে নতুন লোকেল যোগ করুন শুধু বেসিক কভার করা হলে।
• স্ক্রিন-বাই-স্ক্রিন পাস চালান লেআউট সমস্যা ধরতে (দীর্ঘ শব্দ, র‍্যাপিং)।

অনুবাদ প্রায়শই দেরিতে আসে, তাই আগে থেকেই নির্ধারণ করুন "পারশিয়াল" মানে কী আপনার প্রোডাক্টে। যদি কোনো ফিচার কাস্টমার-ফেসিং হয়, তাহলে ফিচার ফ্ল্যাগ বিবেচনা করুন যাতে ফিচার ও তার স্ট্রিং একসাথে শিপ হয়। যদি সম্পূর্ণ অনুবাদ ছাড়াই শিপ করতে হয়, স্পষ্ট ফলব্যাক (যেমন ইংরেজি) পছন্দ করুন খালি লেবেল ছাড়ার চেয়ে, তবে সেটি স্টেজিং-এ জোরালোভাবে দেখান।

কপি আপডেট করলে টিমগুলো কী ভাঙায়। যদি আপনি শব্দ বদলান, কী স্থির রাখুন। কী-গুলো উদ্দেশ্য বর্ণনা করবে, সঠিক বাক্য নয়। কী রিপ্লেস বা রিনেম তখনই করুন যখন অর্থ বদলে যায়, এবং তা নিয়ন্ত্রিত মাইগ্রেশন করে করুন।

"জাম্পি স্ট্রিং" এড়াতে, কীগুলো ডিপ্রিকেট করুন উদ্দেশ্য করে: কীগুলো ডিপ্রিকেটেড হিসেবে মার্ক করুন একটি তারিখ ও রিপ্লেসমেন্ট দিন, এক রিলিজ সাইকেল রাখুন, তারপর নিশ্চিত করুন কোনো রেফারেন্স নেই তখন সরান।

ট্রান্সলেশন নোটগুলো কী-র কাছে রাখুন। যদি আপনার JSON ফরম্যাটে কমেন্ট রাখা না যায়, ছোট একটি সহযোগী ডকুমেন্ট বা পাশের মেটাডেটা ফাইল রাখুন (উদাহরণ: "checkout success screen এ ব্যবহৃত")। এটা বিশেষভাবে সহায়ক যখন আপনার Vue 3 web app AppMaster-এর মতো টুল থেকে জেনারেট হয় এবং একাধিক লোক কপি ও UI টাচ করে।

উদাহরণ: ৬০টি নতুন স্ট্রিং নিয়ে একটি ফিচার শিপ করা

একটি স্প্রিন্টে, টিম তিন কাজ একসঙ্গে শিপ করে: নতুন Settings পেজ, একটি Billing স্ক্রিন, এবং তিনটি ইমেইল টেমপ্লেট (receipt, payment failed, trial ending)। মোট প্রায় ৬০টি নতুন স্ট্রিং—এখানেই সাধারণত i18n গোলমেল শুরু হয়।

টিম সম্মত হয় কীগুলো ফিচারভিত্তিক গ্রুপ করার এবং তারপর সারফেস অনুযায়ী। প্রতিটি ফিচারের জন্য নতুন ফাইল তৈরি করা হয়, এবং কীগুলো সব জায়গায় একই প্যাটার্ন অনুসরণ করে: feature.area.element।

// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",

// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",

// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"

অনুবাদ কাজ শুরু করার আগে, প্লুরাল স্ট্রিংগুলো বাস্তব ভ্যালু দিয়ে টেস্ট করা হয়, অনুমানের উপর নয়। billing.invoice.count-এর জন্য QA 0, 1, 2, এবং 5 টেস্ট করে (সিডড ডেটা বা ডেভ টগল ব্যবহার করে)। এটা অচল কেস ধরার আগে করে দেয়, যেমন "0 invoice"।

QA তারপর একটি ফোকাসড ফ্লো চালায় যা সাধারণত মিসিং কী প্রকাশ করে: Settings ও Billing খুলে প্রতিটি ট্যাবে একবার ক্লিক করা, স্টেজিং-এ টেস্ট অ্যাকাউন্ট দিয়ে প্রতিটি ইমেইল টেমপ্লেট ট্রিগার করা, নন-ডিফল্ট লোকেল সক্রিয় করে অ্যাপ চালানো, এবং লগে কোনো missing-translation সতর্কতা থাকলে বিল্ড ফেল করা।

এই স্প্রিন্টে QA দুটি মিসিং কী পেয়েছিল: Billing স্ক্রিনে একটি লেবেল ও একটি ইমেইল সাবজেক্ট। টিম এগুলো রিলিজের আগে ঠিক করে।

ব্লক করা হবে নাকি ফলব্যাক চালু থাকবে—এই সিদ্ধান্তে তারা একটি সহজ নিয়ম ব্যবহার করে: ইউজার-ফেসিং স্ক্রিন ও ট্রান্স্যাকশনাল ইমেইল ব্লক করে রিলিজ; কম ঝুঁকিপূর্ণ অ্যাডমিন-ওনলি টেক্সট সাময়িকভাবে ডিফল্ট ভাষায় ফলব্যাক করতে পারে, কিন্তু সেটির জন্য টিকিট ও স্পষ্ট ডেডলাইন থাকতে হবে।

পরবর্তী ধাপ ও একটি সহজ রিলিজ চেকলিস্ট

একটি Vue 3 i18n ওয়ার্কফ্লো তখনই স্থিতিশীল থাকে যখন আপনি ট্রান্সলেশনকে কোডের মতো বিবেচনা করেন: প্রতিবার একইভাবে যোগ করুন, টেস্ট করুন, এবং স্কোর রাখুন।

রিলিজ চেকলিস্ট (মার্জের ৫ মিনিট আগে)

• Keys: আপনার নামকরণ প্যাটার্ন অনুসরণ করছে এবং স্কোপ স্পষ্ট (পেজ, ফিচার, কম্পোনেন্ট)।
• Plurals: কমপক্ষে এক ভাষায় বহু-রুল সহ সঠিকভাবে রেন্ডার হচ্ছে কি না নিশ্চিত করুন।
• Placeholders: ভ্যারিয়েবলগুলো আছে, সব জায়গায় একই নামে আছে, এবং বাস্তব ডেটা দিয়ে ঠিক দেখাচ্ছে কি না যাচাই করুন।
• Fallbacks: মিসিং-কী আচরণ আপনার নীতি অনুযায়ী কি না নিশ্চিত করুন।
• Screens: কয়েকটি স্ক্রিন দ্রুত চেক করুন যা ভাঙা সহজ (টেবিল, টোস্ট, মডাল, খালি স্টেট)।

কি মাপবেন (যাতে সমস্যা আগে দেখায়)

কয়েকটি সহজ সংখ্যা বেছে নিন এবং নিয়মিত রিভিউ করুন: টেস্ট রান-এ মিসিং-কী রেট, নন-ডিফল্ট লোকেলগুলোর অনুবাদহীন স্ট্রিং কount, এবং আনইউজড কী কount (অর্থাৎ আর কোথাও উপস্থিত নেই)। যদি পারেন, রিলিজভিত্তিক ট্র্যাক করুন যাতে ট্রেন্ড দেখা যায় এককালীন সমস্যার চেয়ে।

স্ট্রিং যোগ করা, অনুবাদ আপডেট করা, এবং রেজাল্ট যাচাই করার সঠিক ধাপগুলো লিখে রাখুন। সংক্ষিপ্ত রাখুন এবং কী নামকরণ ও প্লুরাল ব্যবহারের উদাহরণ দিন। নতুন কনট্রিবিউটররা এটি পড়ে বুঝে নিতে পারবে।

আপনি যদি ইন্টারনাল টুল বানান, AppMaster (appmaster.io) ব্যবহার করে Vue3 web app ও কম্প্যানিয়ন মোবাইল অ্যাপ জুড়ে UI কপি ও ট্রান্সলেশন কী কনসিস্টেন্ট রাখাটা সহজ হতে পারে, কারণ সবকিছু এক জায়গায় ম্যানেজ করা হয়।

প্রতি স্প্রিন্টে একটি ছোট i18n হেলথ টাস্ক নির্ধারণ করুন: ডেড কী মুছুন, অসমঞ্জস্যপূর্ণ প্লেসহোল্ডার ঠিক করুন, এবং সাম্প্রতিক মিসগুলো রিভিউ করুন। ছোট ক্লিনআপ এক্সপ্লোজিভ প্রোডাকশন-ভিত্তিক ট্রান্সলেশন হান্টকে হার মানায়।