JSON स्थानीयकरण के दौरान किन भागों का अनुवाद किया जा सकता है और किन भागों को नहीं बदला जाना चाहिए?

JSON स्थानीयकरण में एक सामान्य विफलता है: पेज बटन को अंग्रेजी में बदल दिया गया है, लेकिन प्रोग्राम संबंधित कॉन्फ़िगरेशन आइटम नहीं ढूंढ पा रहा है। इसका कारण आमतौर पर यह है कि ऑब्जेक्ट में प्रत्येक स्ट्रिंग को प्रसंस्करण के लिए अनुवादक को सौंप दिया जाता है, और कुंजी नाम, रूटिंग और व्यवसाय एन्कोडिंग भी तदनुसार बदल जाती है। यह आलेख अंतर्राष्ट्रीय कॉन्फ़िगरेशन के लिए जिम्मेदार डेवलपर्स और स्थानीयकरण कर्मियों के लिए लिखा गया है। यह बताता है कि पहले अनुवाद योग्य फ़ील्ड पथों को कैसे चित्रित किया जाए और फिर स्वीकृति कैसे दी जाए।

उदाहरण प्रसंस्करण विधियों को प्रदर्शित करने के लिए सिंथेटिक नमूनों का उपयोग करते हैं, और कोड को एक अलग वातावरण में जांचा गया है, लेकिन यह सभी वास्तविक फ़ाइलों या उत्पाद प्रदर्शन की गारंटी का प्रतिनिधित्व नहीं करता है। महत्वपूर्ण दस्तावेज़ों को संसाधित करने से पहले, कृपया मूल दस्तावेज़ अपने पास रखें और पाठ में सीमाओं और स्वीकृति आइटम के अनुसार उनकी समीक्षा करें।

JSON स्थानीयकरण के दौरान क्या अनुवाद किया जा सकता है? एक वाक्य का निष्कर्ष

केवल पहले से सूचीबद्ध कॉपी राइटिंग पथों का ही अनुवाद किया जाएगा। मुख्य नाम, रूटिंग मान और व्यवसाय कोड समान रहेंगे, और यह पुष्टि करने के लिए एक स्वीकृति चेकलिस्ट का उपयोग किया जाएगा कि अपरिवर्तित भागों को वास्तव में नहीं बदला गया है।

सभी स्ट्रिंग्स को पार करने के बजाय फ़ील्ड पथ से प्रारंभ करें

जब आप इसे देखते हैं तो स्ट्रिंग "सेव" को बदलने की तुलना में buttons.save को एक पते के रूप में मानना अधिक विश्वसनीय है। एक ही वाक्य एक ही समय में इंटरफ़ेस कॉपी, लॉग नमूने और परीक्षण मामलों में दिखाई दे सकता है, और तीनों स्थानों पर अनुवाद की आवश्यकता नहीं हो सकती है।

पथों को टुपल्स या JSON पॉइंटर्स का उपयोग करके स्पष्ट रूप से दर्शाया जाना चाहिए। जब केवल बिंदुओं को जोड़ा जाता है, तो अस्पष्टता उत्पन्न होगी यदि कुंजी नाम में ही बिंदु हों।

निम्नलिखित उदाहरण केवल दो विशिष्ट पथों को सीमित करता है, अन्य सामग्री को वैसे ही छोड़ देता है। यह इस लेख के लिए एक स्थानीयकरण रणनीति है, न कि JSON प्रारूप की आवश्यकता। सिंथेटिक नमूने में इंटरफ़ेस टेक्स्ट और रूटिंग मान दोनों शामिल हैं जिन्हें सीमा जांच की सुविधा के लिए बदला नहीं जाना चाहिए।

एक समय में केवल स्पष्ट रूप से अनुमत मान बदलें

import copy

source = {"buttons": {"save": "保存", "cancel": "取消"},
          "route": "/settings", "version": 1}
approved = {("buttons", "save"): "Save",
            ("buttons", "cancel"): "Cancel"}

def apply_texts(document, replacements):
    result = copy.deepcopy(document)
    for path, translated in replacements.items():
        if not path or not isinstance(translated, str):
            raise ValueError("invalid replacement")
        parent = result
        for key in path[:-1]:
            parent = parent[key]
        key = path[-1]
        if key not in parent or not isinstance(parent[key], str):
            raise ValueError("target must be an existing string")
        parent[key] = translated
    return result

result = apply_texts(source, approved)
assert result["buttons"]["save"] == "Save"
assert result["route"] == source["route"]
assert source["buttons"]["save"] == "保存"
try:
    apply_texts(source, {("version",): "one"})
except ValueError:
    pass
else:
    raise AssertionError("numeric field must be rejected")

उदाहरण केवल ऑब्जेक्ट स्तर को प्रदर्शित करता है, सरणी अनुक्रमण को लागू नहीं करता है, और अनुवाद सेवा को कॉल नहीं करता है। वास्तविक पाइपलाइन में सबमिट करते समय, अनुमत पथों की सूची अनुवाद से पहले निर्धारित की जानी चाहिए, और अनुवाद उत्पन्न करने वाली पार्टी को एक ही समय में अपने स्वयं के संशोधनों के दायरे का विस्तार करने की अनुमति नहीं दी जा सकती है।

डीप कॉपी इनपुट ऑब्जेक्ट को उसके स्थान पर संशोधित होने से रोक सकती है, लेकिन यह एक लेनदेन प्रणाली नहीं है। दृढ़ता को अभी भी अलग से डिज़ाइन करने की आवश्यकता है।

स्वीकृति अपरिवर्तित भागों पर निर्भर करती है

केवल यह सत्यापित करना कि "लक्ष्य भाषा मौजूद है" पर्याप्त नहीं है। स्रोत फ़ाइल हैश और पथों की एक सूची भी सहेजी जानी चाहिए। यदि स्रोत फ़ाइल अद्यतन होने के बाद पथ हटा दिया जाता है, तो पुराने अनुवाद को समान फ़ील्ड नामों के साथ स्वचालित रूप से वापस नहीं लिखा जा सकता है।

ऐरे, शून्य मान और डुप्लिकेट कुंजियों पर अलग से विचार करने की आवश्यकता है

• सरणी: तत्वों को पुनर्व्यवस्थित करने के बाद, सूचकांक अभी भी मूल प्रति की ओर इंगित नहीं कर सकता है। जब कोई स्थिर आईडी होती है, तो मैपिंग के लिए सबसे पहले आईडी का उपयोग किया जाता है।
• शून्य: null एक खाली स्ट्रिंग नहीं है और अनुवाद की सुविधा के लिए इसे शाब्दिक "खाली" से प्रतिस्थापित नहीं किया जाना चाहिए।
• डुप्लिकेट कुंजी: सामान्य JSON पार्सिंग पूरी होने के बाद डुप्लिकेट कुंजी जानकारी खो गई होगी। यदि आप डुप्लिकेट कुंजियों को अस्वीकार करना चाहते हैं, तो आपको अनुवाद समाप्त होने की प्रतीक्षा करने के बजाय उन्हें पार्सिंग चरण के दौरान संभालना चाहिए। संदर्भ पायथन JSON दस्तावेज़ीकरण.

यह उदाहरण अच्छी तरह से संरचित कॉन्फ़िगरेशन स्थानीयकरण के लिए उपयुक्त है, मनमाने ढंग से JSON ऑटो-अनुवादक के लिए नहीं। अनुवाद स्वीकार करते समय, पहले पुष्टि करें कि संरचना और संरक्षित क्षेत्र नहीं बदले हैं, और फिर चर्चा करें कि क्या भाषा प्राकृतिक है। समस्या निवारण क्रम स्पष्ट हो जाएगा.

📊 कोर तुलना

🎯कौन सा तरीका आपके लिए उपयुक्त है?

अगर आप……

• इंटरफ़ेस कॉन्फ़िगरेशन फ़ाइल को बनाए रखने के लिए, यदि आप चाहते हैं कि बटन कॉपी अनुवाद योग्य हो और प्रोग्राम कॉन्फ़िगरेशन अपरिवर्तित रहे, तो कृपया फ़ील्ड पथ श्वेतसूची का उपयोग करें और अनुवाद से पहले पथ सूची निर्धारित करें।
• ऐरे तत्वों को पुनर्व्यवस्थित किया जा सकता है, कृपया इंडेक्स पर भरोसा करने के बजाय मैपिंग के लिए स्थिर आईडी का उपयोग करने को प्राथमिकता दें।
• स्रोत फ़ाइल लगातार अद्यतन की जाएगी। कृपया स्रोत फ़ाइल हैश और पथ सूची सहेजें। यदि पथ गायब हो जाता है, तो एक त्रुटि उत्पन्न होगी और पुराना अनुवाद स्वचालित रूप से वापस नहीं लिखा जाएगा।
• यदि आपको वास्तविक दस्तावेज़ों की डिलीवरी की प्रक्रिया करने की आवश्यकता है, तो कृपया अनुमत पथों, मूल पाठ और अनुवाद की समीक्षा सूची बनाएं और एक-एक करके उनकी समीक्षा करें।

❓ अक्सर पूछे जाने वाले प्रश्न (FAQ)

1. JSON में सभी स्ट्रिंग्स का सीधे अनुवाद क्यों नहीं किया जाता?

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

2. पथों को जोड़ने के लिए बिंदुओं का उपयोग करने में क्या समस्या है?

यदि कुंजी नाम में ही एक अवधि शामिल है, तो बिंदु संयोजन अस्पष्टता का कारण बनेगा। मूल लेख टुपल्स या JSON पॉइंटर्स जैसे स्पष्ट अभ्यावेदन का उपयोग करने की अनुशंसा करता है।

3. क्या केवल यह जांचना पर्याप्त है कि अनुवाद में लक्ष्य भाषा शामिल है या नहीं?

पर्याप्त नहीं। आपको यह भी जांचना चाहिए कि क्या कुंजी नामों का सेट स्रोत फ़ाइल के अनुरूप है, क्या अनधिकृत पथ का मान अपरिवर्तित रहता है, क्या लक्ष्य फ़ील्ड अभी भी एक स्ट्रिंग है, और क्या लापता पथ स्पष्ट रूप से त्रुटियों के रूप में रिपोर्ट किए गए हैं।

4. क्या null को "खाली" टेक्स्ट से बदला जा सकता है?

नहीं कर सकता। null एक खाली स्ट्रिंग नहीं है और अनुवाद की सुविधा के लिए इसे टेक्स्ट से प्रतिस्थापित नहीं किया जाना चाहिए।

5. सरणियों का अनुवाद करते समय मैपिंग के लिए क्या उपयोग किया जाना चाहिए?

जब कोई स्थिर आईडी होती है, तो मैपिंग के लिए सबसे पहले आईडी का उपयोग किया जाता है। केवल सूचकांक पर भरोसा करते हुए, तत्वों को पुनर्व्यवस्थित करने के बाद गलत प्रतिलिपि का मिलान किया जा सकता है।

📝सारांश

JSON कॉन्फ़िगरेशन का अनुवाद करने से पहले, पहले उन पथों को स्पष्ट करें जो अनुवाद की अनुमति देते हैं, और फिर अपरिवर्तित भागों की जांच करने के लिए स्वीकृति चेकलिस्ट का उपयोग करें। इससे कुछ गलत होने पर समस्या का पता लगाना आसान हो जाता है।

इसे अभी आज़माएं: मूल लेआउट को बरकरार रखते हुए अनुवाद शुरू करने के लिए दस्तावेज़ अपलोड करें