حال ہی میں ریلیز ہونے والے Cache-Control analyzer کے انگریزی ورژن میں جاپانی متن نظر آیا—اس کی صورتحال "Fresh" کے بجائے "新鮮" دکھائی دے رہی تھی۔ یہ غلطی اس مشترکہ لاجک (shared logic) کی وجہ سے ہوئی جو ہارڈ کوڈڈ جاپانی اسٹرنگز واپس کر رہی تھی، جبکہ پیج صرف انگریزی لیبل فراہم کر رہا تھا۔
ڈویلپر ہلکے پھلکے براؤزر ٹولز کا ایک سلسلہ بناتا ہے، جن میں سے ہر ایک کا ایک انگریزی پیج اور ایک جاپانی پیج ہوتا ہے جو ایک ہی پارسنگ فنکشنز اور کور لاجک کو دوبارہ استعمال کرتے ہیں۔ صرف ظاہری الفاظ میں فرق ہونا چاہیے۔ جب Cache-Control analyzer ریلیز ہوا، تو انگریزی انٹرفیس نے درست لیبل دکھائے، لیکن جو ویلیوز اس نے رینڈر کیں وہ لاجک لیئر سے آئی تھیں، جس میں اب بھی جاپانی الفاظ موجود تھے۔ کوئی کنسول ایرر ظاہر نہیں ہوا؛ پیج معمول کے مطابق نظر آ رہا تھا، پھر بھی انگریزی بولنے والے صارفین کو پیش کی جانے والی معلومات غلط تھیں۔
مشترکہ لاجک ترجمہ کے ساتھ دھوکہ کیوں دے سکتی ہے
یہ بگ ایک ڈیزائن کے انتخاب کا نتیجہ تھا: وہ بنیادی فنکشن جو یہ فیصلہ کرتا ہے کہ کیا دکھانا ہے، جاپانی زبان میں لٹریل اسٹرنگز (literal strings) واپس کر رہا تھا۔ پیج لیئر، جو ارد گرد کے انگریزی متن کے لیے ذمہ دار تھی، اسے ان ویلیوز کو تبدیل کرنے کا موقع ہی نہیں ملا۔ چونکہ لاجک اور UI کو واضح طور پر الگ کیا گیا تھا، اس لیے ٹیسٹنگ کے دوران یہ مسئلہ نظر نہیں آیا—تکنیکی طور پر سب کچھ "کام" کر رہا تھا، اگرچہ صارف کے لیے استعمال ہونے والی زبان غلط تھی۔
اس کا نقصان یہ ہے کہ مشترکہ ماڈیول کے اندر استعمال ہونے والی زبان ہر اس فرنٹ اینڈ کے لیے ڈیفالٹ بن جاتی ہے جو اسے استعمال کرتا ہے۔ اگر کسی دوسری زبان کی ضرورت ہو، تو یہ ڈیفالٹ ایک چھپا ہوا بگ بن جاتا ہے۔
حل: کیز، پیکس، اور ایک حفاظتی جال
مصنف نے ذمہ داریوں کو الگ کرنے کے لیے آرکیٹیکچر کو دوبارہ لکھا:
- Message packs اب ہر زبان کے لیے تمام انسانی طور پر پڑھنے کے قابل اسٹرنگز کو محفوظ رکھتے ہیں۔
- Shared logic صرف علامتی کیز (symbolic keys) واپس کرتا ہے، کبھی بھی خام متن (raw text) نہیں۔
- Pages متعلقہ کی (key) کی بنیاد پر متعلقہ پیک سے مناسب لفظ تلاش کرتے ہیں۔
جب کسی پیغام میں نمبر شامل کرنا ضروری ہو، تو نیا کوڈ ٹیمپلیٹ اسٹرنگ کے بجائے ایک چھوٹا فنکشن استعمال کرتا ہے۔ یہ ہر زبان کو یہ فیصلہ کرنے کی اجازت دیتا ہے کہ نمبر کہاں ہونا چاہیے، جس سے الفاظ کی ترتیب کے فرق کو سنبھالا جا سکے۔
ایک سادہ اسٹیٹک اینالیسس (static-analysis) مرحلہ بھی شامل کیا گیا: بلڈ پروسیس مشترکہ فائلوں میں جاپانی حروف کی جانچ کرتا ہے۔ اگر کوئی بھی نظر آئے، تو ڈویلپر کو فوری طور پر مطلع کر دیا جاتا ہے، جس سے ہارڈ کوڈڈ غیر ملکی متن کے دوبارہ شامل ہونے کا خطرہ ٹل جاتا ہے۔
اس تجربے نے مصنف کو کیا سکھایا
- ترجمہ ایک ریویو پاس کے طور پر کام کرتا ہے۔ انگریزی پیغامات لکھتے وقت، مصنف نے محسوس کیا کہ کچھ جاپانی متبادل مبہم تھے۔ ترجمہ کرنے سے دونوں زبانوں میں واضح جملہ سازی کرنے پر مجبور ہونا پڑا۔
- مشترکہ فنکشنز جو اسٹرنگز واپس کرتے ہیں، سب کے لیے ایک زبان کو مقفل کر دیتے ہیں۔ اگر کوئی فنکشن زبان کا فیصلہ کرتا ہے، تو کوئی بھی صارف جو مختلف زبان کی توقع رکھتا ہے، وہی غلطی ورثے میں پاتا ہے۔ یہ بگ صرف ایک UI کی خرابی نہیں ہے؛ یہ لاجک کی خامی ہے۔
کثیر لسانی ٹولز کو برقرار رکھنے والوں کے لیے سفارشات
- کور فنکشنز سے اسٹرنگز کے بجائے کیز (keys) واپس کریں۔ لوکلائزیشن (localization) کا کام UI لیئر پر چھوڑ دیں۔
- یا مطلوبہ اسٹرنگز کو پیرامیٹرز کے طور پر فنکشن میں پاس کریں۔ یہ لاجک کو زبان سے آزاد رکھتا ہے۔
- مشترکہ ماڈیولز کا آڈٹ کریں کہ کہیں ان میں ہارڈ کوڈڈ مقامی زبان کا متن تو نہیں ہے۔ نان-ASCII کیریکٹرز کی فوری تلاش چھپے ہوئے مسائل کو سامنے لا سکتی ہے۔
- مشترکہ کوڈ میں غیر ملکی حروف کے لیے بلڈ ٹائم چیک شامل کریں۔ جلد شناخت کرنا ریلیز کے بعد کی الجھن سے بہتر ہے۔
آگے کیا دیکھنا ہے
حاصلِ کلام: اگر آپ کا پروجیکٹ مختلف زبانوں کے ورژن کے درمیان کوڈ شیئر کرتا ہے، تو اس بات کو یقینی بنائیں کہ مشترکہ حصہ کبھی بھی الفاظ کا فیصلہ نہ کرے۔ ہر پیج کو اپنے الفاظ خود فراہم کرنے دیں، اور آپ اس شرمندگی سے بچ جائیں گے کہ ایک انگریزی پیج غلطی سے جاپانی بولنے لگے۔