क्या मैं कोर में उपयोग किए गए शब्दों के लिए प्लगइन टेक्सटोमैन को छोड़ सकता हूं?

10

मुझे एक प्लगइन मिला है जो पोस्ट स्टेटस को पोस्ट टाइप एडमिन मेन्यू में डालता है। मैं इसे अंतर्राष्ट्रीयकरण करने के बीच में हूं, और मैं सोच रहा हूं कि इस स्थिति को कैसे संभालना है।

प्लगइन कुछ अद्वितीय तार का उपयोग करता है जो इस तरह एक टेक्सटोमैन प्राप्त करेगा:

__( 'Select the post statuses to <strong>exclude</strong> from post type admin menus', 'csmpmsi' )

लेकिन फिर वहाँ भी मामले हैं, जहां मैं इस तरह अपने मूल से संबंधित अर्थ के लिए एक कोर से संबंधित शब्द का उपयोग कर रहा है: __( 'Pages' )। इस स्थिति में, टेक्सटोमैन को बाहर करने और कोर में पहले से ही स्थानीयकृत शर्तों का लाभ उठाने के लिए मेरे लिए यह सही समझ में आता है। हालाँकि, कोडेक्स बहुत स्पष्ट है:

यदि आप एक प्लगइन का अनुवाद करने की कोशिश कर रहे हैं, तो उपरोक्त सलाह वही लागू होती है, सिवाय इसके कि

आपको एक डोमेन का उपयोग करना चाहिए, जो आपके प्लगइन के हुक में लोड किया गया है

हर अनुवाद कॉल __ ('पाठ', 'डोमेन-नाम') बननी चाहिए

तो क्या यह WP-kosher है?

plugins localization

— mrwweb
स्रोत

1

एक सोचा-समझा सवाल पूछने के लिए धन्यवाद, जवाब (अब तक के स्कोच और मार्क कप्लून से) मेरे लिए दिलचस्प और उपयोगी रहा है!

— 23

14

कभी भी अनुवाद के लिए मूल तार पर निर्भर न रहें, वे contextकिसी भी समय बदल सकते हैं या एक पैरामीटर प्राप्त कर सकते हैं । एक बार ऐसा होने पर आपके उपयोगकर्ताओं को आंशिक रूप से अनुवादित इंटरफ़ेस मिलता है, और आपके अनुवादकों के पास इसे ठीक करने का कोई तरीका नहीं है।

यह भी ध्यान रखें कि एक ही शब्द के साथ हर जगह एक ही स्ट्रिंग का अनुवाद आवश्यक नहीं है। संदर्भ पैरामीटर के बिना भी कुछ भाषाओं में अपने प्लगइन के लिए एक अलग अनुवाद का उपयोग करना उपयोगी हो सकता है। लेकिन यह संभव नहीं होगा यदि आप स्ट्रिंग को अपने प्लगइन में शामिल नहीं करते हैं।

इस देखें चैट चर्चा हम कुछ दिन पहले किया था इस विषय के बारे में।

— फक्सिया
स्रोत

यह भी ध्यान रखें कि स्ट्रिंग अभी भी आपके POT फ़ाइल में दिखाई देगी, भले ही उसमें टेक्सडोमैन न हो।

— 5

@ Scribu पार्सर पर निर्भर करता है। कोडैलाइजिंग स्थानीयकरण प्लगइन इसे अनदेखा करेगा।

— FUXIA

ऐसा लगता है कि इस जवाब और इस जवाब के बीच कुछ असहमति का सवाल है ...

— mrwweb

4

हाँ, लेकिन कृपया नहीं। यह कोडिंग मानक की तरह है, जब आप इसे दरकिनार कर एक छोटा लाभ प्राप्त कर सकते हैं तो भी बेहतर तरीके से इसका पालन करें।

बेहतर कारण:

संस्करण 3.5 वर्डप्रेस में एक मोनोलिथ अनुवाद फाइलें नहीं हैं, इसे प्रदर्शन कारणों से 3 भाग में तोड़ा गया। यदि यह प्रवृत्ति जारी रहती है, तो क्या आप सुनिश्चित कर सकते हैं कि जब आप इसका उपयोग करने का प्रयास करेंगे तो डिफ़ॉल्ट डोमेन बिल्कुल लोड हो जाएगा __('Pages')?
आप स्थानीयकरण के लिए काम नहीं बचाते हैं - पोएडिट जैसे अनुवाद टूल को पता नहीं है कि एक फ़ाइल में दो अनुवाद डोमेन के साथ कैसे व्यवहार करें, और आपके उदाहरण में वे एक .po फ़ाइल उत्पन्न करेंगे जिसमें 'पेज' शब्द शामिल है भले ही आप। इसके लिए डिफ़ॉल्ट डोमेन का उपयोग करें। स्थानीय व्यक्ति अपने द्वारा अनुवादित स्ट्रिंग्स के वास्तविक उपयोग की जांच नहीं करता है जब तक कि उसे संदर्भ को समझने की आवश्यकता न हो इसलिए वह अलग डोमेन को नोटिस नहीं करेगा और शब्द का अनुवाद करेगा। इसके अलावा, अगर स्थानीय व्यक्ति को अपने टूल का पता है, तो उसके पास वर्डप्रेस कोर ट्रांसलेशन फ़ाइलों के आधार पर एक अनुवाद डीबी होगा, जो कवि को स्वचालित रूप से 'पेज' जैसे शब्दों का अनुवाद करने में सक्षम बनाता है।

— मार्क कप्लून
स्रोत

0

आप इसे आज़मा सकते हैं

add_action('wp',function(){
    load_default_textdomain();
    _e('Settings');
});

या

add_action('wp',function(){
    $locale = is_admin() ? get_user_locale() : get_locale();
    load_textdomain( 'default', WP_LANG_DIR . "/$locale.mo" );
    load_textdomain( 'default', WP_LANG_DIR . "/admin-$locale.mo" );

    // WPMU
    //load_textdomain( 'default', WP_LANG_DIR . "/ms-$locale.mo" );
    //load_textdomain( 'default', WP_LANG_DIR . "/admin-network-$locale.mo" );

    _e('Settings');
    _e('First Name');
    _e('Last Name');
});

संदर्भ 123 https://v123.tw/use-wordpress-core-translation/

सौभाग्य!!

— ऐन
स्रोत