अनुवादित लोकलाइज़ेशन फ़ाइलें ऐप्स को क्यों तोड़ती हैं

लोकलाइज़ेशन फ़ाइल ऐसा कोड है जिसके अंदर वाक्य हैं

PO, YAML, .properties, RESX, XLIFF और JSON लोकेल फ़ाइलें वाक्यों की सूची जैसी दिखती हैं, लेकिन सिर्फ़ वैल्यू ही गद्य होती हैं। की (key) ऐसे आइडेंटिफ़ायर हैं जिन्हें कोड खोजता है; प्लेसहोल्डर ऐसे स्लॉट हैं जिन्हें कोड रनटाइम पर भरता है; एस्केप और मार्कअप ऐसा सिंटैक्स हैं जिस पर पार्सर निर्भर करता है। जो अनुवादक पूरी लाइन को टेक्स्ट मानकर चलता है, वह ऐसी फ़ाइल बनाएगा जो पढ़ने में शानदार लगती है पर लोड नहीं होती, या लोड होती है और फिर पहली बार किसी स्क्रीन के कोई संख्या फ़ॉर्मेट करते ही क्रैश हो जाती है। यह गड़बड़ी आमतौर पर सिर्फ़ एक भाषा में दिखती है, इसलिए रिव्यू में इसे पकड़ना सबसे मुश्किल होता है।

पाँच चीज़ें जो अनुवाद के बाद भी बिना बदले बचनी चाहिए

की और रिसोर्स नाम — कोड स्ट्रिंग्स को की से खोजता है, इसलिए अनुवादित की का मतलब बस एक गायब स्ट्रिंग है।
प्लेसहोल्डर — %s, %1$d, {0}, {name} और ICU आर्ग्युमेंट कोड भरता है; इनमें से किसी एक का नाम बदलने या उसे हटाने से फ़ॉर्मेटिंग टूट जाती है या रनटाइम पर एरर आता है।
एस्केप और एन्कोडिंग नियम — क्लासिक Properties.load(InputStream) मेथड से पढ़ी जाने वाली .properties फ़ाइल को Latin-1 माना जाता है, और बाकी कैरेक्टर \uXXXX एस्केप के रूप में लिखे जाते हैं, इसलिए कच्चा गैर-लैटिन टेक्स्ट अपठनीय अक्षरों (mojibake) में बदल सकता है।
स्ट्रिंग्स के अंदर मार्कअप — HTML टैग, XLIFF इनलाइन कोड और Markdown संतुलित रहने चाहिए, वरना रेंडर की गई स्ट्रिंग अपने आसपास के पेज को तोड़ देती है।
फ़ाइल संरचना — YAML इंडेंटेशन, ब्लॉक स्केलर, एंकर और एलियस, और XML नेस्टिंग सिंटैक्स हैं; खिसका हुआ इंडेंट या अनुवादित एंकर नाम फ़ाइल का मतलब बदल देता है।

बहुवचन का मतलब एकवचन के साथ "s" जोड़ना नहीं है

अंग्रेज़ी में बहुवचन के दो रूप होते हैं, इसलिए यह मान लेना आसान है कि हर भाषा में ऐसा ही है। GNU gettext मैनुअल दिखाता है कि यह धारणा क्यों गलत है: हर भाषा अपना Plural-Forms नियम घोषित करती है, अंग्रेज़ी nplurals=2 का उपयोग करती है, और रूसी को तीन रूपों की ज़रूरत होती है जो संख्या के आखिरी अंकों के आधार पर चुने जाते हैं। रूसी में अनुवादित कोई PO फ़ाइल, जिसमें सिर्फ़ दो रूप भरे हों, कंपाइल होती है, चलती है, और 2, 3 या 4 पर खत्म होने वाली हर गिनती के लिए गलत व्याकरण दिखाती है। बहुवचन को सही ढंग से संभालने का मतलब है उतनी msgstr एंट्री बनाना जितनी लक्ष्य भाषा को चाहिए, न कि उतनी जितनी स्रोत भाषा में संयोग से थीं।

कभी-कभी प्लेसहोल्डर को जगह बदलनी पड़ती है

अलग-अलग भाषाओं में शब्दों का क्रम अलग होता है, इसलिए दो वैल्यू वाले वाक्य में अक्सर उन्हें उल्टे क्रम में रखना पड़ता है। %1$s और %2$s जैसे पोज़िशनल प्लेसहोल्डर, या {count} और {user} जैसे नामित प्लेसहोल्डर, ठीक इसी के लिए होते हैं: अनुवाद उनका क्रम बदल सकता है, लेकिन हर एक को अब भी ठीक एक बार मौजूद रहना चाहिए। अकेले %s जैसे बेनाम प्लेसहोल्डर का क्रम सुरक्षित रूप से नहीं बदला जा सकता, और यह ऐसी समस्या है जिसे अनुवाद के बाद नहीं, बल्कि पहले ही स्रोत स्ट्रिंग्स में ठीक कर लेना चाहिए।

अनुवाद से पहले जानने लायक फ़ॉर्मेट नियम

हर फ़ॉर्मेट की अपनी पेचीदगियाँ हैं। YAML में, स्पेसिफ़िकेशन लिटरल ब्लॉक (|) और फ़ोल्डेड ब्लॉक (>) को लाइन-ब्रेक का अलग-अलग व्यवहार देता है, और एंकर (&) और एलियस (*) एक नोड को दूसरे नोड का दोबारा उपयोग करने देते हैं, इसलिए दोनों को बिना छुए आगे जाना चाहिए। XLIFF 2.1 मूल फ़ॉर्मेटिंग को <ph> और <pc> जैसे इनलाइन एलिमेंट में लपेटता है, जिन्हें अनुवाद को सही शब्दों के आसपास उनकी जगह पर बनाए रखना होता है। .NET में, RESX रिसोर्स रनटाइम पर मौजूदा UI कल्चर के लिए नाम से खोजे जाते हैं, इसलिए नाम बदला हुआ data एलिमेंट चुपचाप डिफ़ॉल्ट भाषा पर लौट जाता है। और Java की .properties फ़ाइल पहले बिना एस्केप वाले =, : या व्हाइटस्पेस को की सेपरेटर मानती है, इसलिए अनुवादित की में भटका हुआ कोलन उसे दो हिस्सों में बाँट देता है।

रिव्यू चेकलिस्ट जो ज़्यादातर गड़बड़ियाँ पकड़ लेती है

हर स्रोत और लक्ष्य स्ट्रिंग में प्लेसहोल्डर गिनें — मल्टीसेट मेल खाना चाहिए, भले ही क्रम मेल न खाए।
वैल्यू नहीं, की की तुलना करें — स्रोत में मौजूद कोई भी की जो लक्ष्य में गायब हो या जिसका नाम बदल गया हो, एक बग है।
शिप करने से पहले अनुवादित फ़ाइल को असली पार्सर (msgfmt, YAML लोडर, ResXResourceReader) से लोड करें।
बहुवचन एंट्री को स्रोत भाषा के नहीं, लक्ष्य भाषा के नियम के हिसाब से जाँचें।
सबसे लंबे अनुवाद को सबसे तंग UI एलिमेंट में रेंडर करें — दूसरी भाषाओं का टेक्स्ट अक्सर अंग्रेज़ी से लंबा होता है।

कोई ऐप एक भाषा में क्रैश क्यों होता है, लेकिन बाकी भाषाओं में नहीं?

लगभग हमेशा इसलिए कि सिर्फ़ उसी भाषा में कोई प्लेसहोल्डर बदल दिया गया — उसका नाम बदला गया, उसे हटा दिया गया, या उसे दोहरा दिया गया। कोड हर भाषा को एक जैसे आर्ग्युमेंट देता है, इसलिए जो एक अनुवाद अब उनसे मेल नहीं खाता, वह उस स्क्रीन के फ़ॉर्मेट होते समय फ़ेल हो जाता है।

जब अंग्रेज़ी को दो बहुवचन स्ट्रिंग चाहिए, तो रूसी को तीन क्यों चाहिए?

बहुवचन के नियम भाषा के होते हैं, सॉफ़्टवेयर के नहीं। Gettext हर भाषा को अपना नियम घोषित करने देता है; रूसी संख्या के आखिरी अंकों के आधार पर तीन रूपों में से चुनती है, इसलिए सिर्फ़ दो रूपों वाला अनुवाद कई गिनतियों के लिए गलत व्याकरण दिखाता है।

Java की .properties फ़ाइल में एक्सेंट वाले अक्षर बिगड़कर कचरा क्यों बन जाते हैं?

क्योंकि क्लासिक Properties.load(InputStream) फ़ाइल को Latin-1 के रूप में पढ़ता है। उस दायरे से बाहर के कैरेक्टर \uXXXX एस्केप के रूप में लिखने होते हैं, या फ़ाइल को ऐसे रीडर से लोड करना होता है जो सही एन्कोडिंग का उपयोग करे।

क्या अनुवाद प्लेसहोल्डर का क्रम बदल सकता है?

हाँ, जब वे पोज़िशनल (%1$s, %2$s) या नामित ({count}, {user}) हों — स्वाभाविक शब्द-क्रम के लिए अक्सर क्रम बदलना ज़रूरी होता है। फिर भी हर प्लेसहोल्डर को ठीक एक बार आना चाहिए। अकेले %s प्लेसहोल्डर का क्रम सुरक्षित रूप से नहीं बदला जा सकता।

की का अनुवाद कभी क्यों नहीं करना चाहिए?

की आइडेंटिफ़ायर हैं, टेक्स्ट नहीं। कोड किसी स्ट्रिंग को उसकी की से माँगता है; अनुवादित की का मतलब है कि खोज फ़ेल हो जाती है और ऐप कच्ची की दिखाता है या डिफ़ॉल्ट भाषा पर लौट जाता है।