हाल ही में रिलीज़ किए गए Cache-Control analyzer के अंग्रेज़ी वर्शन में जापानी टेक्स्ट दिखाई दिया—इसका स्टेटस "Fresh" के बजाय "新鮮" दिखा रहा था। इस गलती की जड़ वह साझा लॉजिक (shared logic) थी जो हार्ड-कोडेड जापानी स्ट्रिंग्स वापस कर रहा था, जबकि पेज केवल अंग्रेज़ी लेबल ही प्रदान कर रहा था।
डेवलपर हल्के-फुल्के (lightweight) ब्राउज़र टूल्स की एक श्रृंखला बनाता है, जिनमें से प्रत्येक में एक अंग्रेज़ी पेज और एक जापानी पेज होता है जो एक ही पार्सिंग फंक्शन और कोर लॉजिक का पुन: उपयोग करते हैं। केवल दिखने वाली शब्दावली अलग होनी चाहिए। जब Cache-Control analyzer रिलीज़ हुआ, तो अंग्रेज़ी इंटरफ़ेस ने सही लेबल तो दिखाए, लेकिन जो वैल्यूज़ रेंडर हुईं वे लॉजिक लेयर से आईं, जिसमें अभी भी जापानी लिटरल (literals) मौजूद थे। कोई कंसोल एरर नहीं आया; पेज सामान्य लग रहा था, फिर भी अंग्रेज़ी बोलने वाले उपयोगकर्ताओं को दी गई जानकारी गलत थी।
साझा लॉजिक अनुवाद के साथ विश्वासघात क्यों कर सकता है
यह बग एक डिज़ाइन विकल्प के कारण हुआ: वह कोर फंक्शन जो यह तय करता है कि क्या दिखाना है, वह जापानी में लिटरल स्ट्रिंग्स वापस कर रहा था। पेज लेयर, जो आसपास के अंग्रेज़ी टेक्स्ट के लिए ज़िम्मेदार थी, उसे उन वैल्यूज़ को बदलने का मौका ही नहीं मिला। क्योंकि लॉजिक और UI स्पष्ट रूप से अलग थे, इसलिए टेस्टिंग के दौरान समस्या दिखाई नहीं दी—तकनीकी रूप से सब कुछ "काम कर रहा था", भले ही उपयोगकर्ता के सामने दिखने वाली भाषा गलत थी।
इसका नुकसान यह है कि साझा मॉड्यूल के अंदर उपयोग की जाने वाली भाषा हर उस फ्रंट-एंड के लिए डिफ़ॉल्ट बन जाती है जो इसका उपयोग करता है। यदि किसी अन्य भाषा की आवश्यकता होती है, तो यह डिफ़ॉल्ट एक छिपा हुआ बग बन जाता है।
समाधान: कीज़ (keys), पैक्स और एक सेफ्टी नेट
लेखक ने कार्यों को अलग करने के लिए आर्किटेक्चर को फिर से लिखा:
- Message packs अब प्रत्येक भाषा के लिए सभी मानव-पठनीय (human-readable) स्ट्रिंग्स रखते हैं।
- Shared logic केवल प्रतीकात्मक कीज़ (symbolic keys) वापस करता है, कभी भी रॉ टेक्स्ट नहीं।
- Pages की (key) के आधार पर संबंधित पैक से उचित शब्द खोजते हैं।
जब किसी मैसेज में नंबर शामिल करना आवश्यक हो, तो नया कोड टेम्पलेट स्ट्रिंग के बजाय एक छोटे फंक्शन का उपयोग करता है। इससे प्रत्येक भाषा यह तय कर सकती है कि नंबर कहाँ होना चाहिए, जिससे शब्दों के क्रम में अंतर को समायोजित किया जा सके।
एक सरल स्टैटिक-एनालिसिस स्टेप भी जोड़ा गया: बिल्ड प्रोसेस साझा फ़ाइलों में जापानी अक्षरों को स्कैन करता है। यदि कोई भी अक्षर दिखाई देता है, तो डेवलपर को तुरंत सूचित कर दिया जाता है, जिससे हार्ड-कोडेड विदेशी टेक्स्ट के वापस आने की संभावना को रोका जा सके।
इस अनुभव ने लेखक को क्या सिखाया
- अनुवाद एक रिव्यू पास के रूप में कार्य करता है। अंग्रेज़ी मैसेज लिखते समय, लेखक ने गौर किया कि कुछ जापानी समकक्ष अस्पष्ट थे। अनुवाद करने से दोनों भाषाओं में अधिक स्पष्ट वाक्यांश लिखने की आवश्यकता महसूस हुई।
- स्ट्रिंग्स वापस करने वाले साझा फंक्शन सभी के लिए एक भाषा को लॉक कर देते हैं। यदि कोई फंक्शन भाषा तय करता है, तो कोई भी उपभोक्ता जो अलग भाषा की अपेक्षा करता है, वह उस गलती को विरासत में प्राप्त कर लेता है। यह बग कोई UI ग्लिच नहीं है; यह एक लॉजिक दोष है।
बहुभाषी टूल्स का रखरखाव करने वालों के लिए सिफारिशें
- कोर फंक्शन्स से स्ट्रिंग्स के बजाय कीज़ (keys) वापस करें। UI लेयर को लोकलाइजेशन (localization) संभालने दें।
- या वांछित स्ट्रिंग्स को पैरामीटर के रूप में फंक्शन में पास करें। इससे लॉजिक भाषा से स्वतंत्र रहता है।
- हार्ड-कोडेड मूल-भाषा टेक्स्ट के लिए साझा मॉड्यूल का ऑडिट करें। नॉन-ASCII अक्षरों के लिए एक त्वरित खोज छिपी हुई समस्याओं को सामने ला सकती है।
- साझा कोड में विदेशी अक्षरों के लिए बिल्ड-टाइम चेक जोड़ें। समय से पहले पहचान करना रिलीज़ के बाद होने वाली उलझन से बेहतर है।
आगे क्या ध्यान रखें
निष्कर्ष (Takeaway): यदि आपका प्रोजेक्ट विभिन्न भाषा वर्शन के बीच कोड साझा करता है, तो सुनिश्चित करें कि साझा हिस्सा कभी भी शब्दावली तय न करे। प्रत्येक पेज को अपने शब्द स्वयं प्रदान करने दें, और आप एक ऐसे अंग्रेज़ी पेज की शर्मिंदगी से बच जाएंगे जो गलती से जापानी बोलने लगता है।