Çekirdekte kullanılan terimler için eklenti metin alanını bırakabilir miyim?

10

Posta durumlarını yazı tipi yönetici menülerine koyan bir eklentim var . Uluslararasılaşmanın tam ortasındayım ve bu durumun üstesinden nasıl geleceğini merak ediyorum.

Eklenti, böyle bir metin alanı alacak bazı benzersiz dizeler kullanır:

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

Böyle kendi çekirdek-ilişkili anlam çekirdek ilişkili kelimeyi kullanıyorum nerede Ama sonra durumlar da vardır: __( 'Pages' ). Bu durumda, metin alanını hariç tutmak ve çekirdekte zaten yerelleştirilmiş olan terimlerden yararlanmak benim için mükemmel bir mantıklı görünüyor. Ancak, kodeks çok açık görünüyor:

Bir eklentiyi çevirmeye çalışıyorsanız, bunun dışında yukarıdaki tavsiyenin aynısı geçerlidir

eklentinizin kancasına yüklenmiş bir alan kullanmalısınız

her çeviri çağrısı __ olmalıdır ('metin', 'alan adı')

Peki bu WP-koşer mi?

plugins localization

— mrwweb
kaynak

1

Düşündürücü bir soru sorduğunuz için teşekkürler, (şimdiye kadar toscho ve Mark Kaplun'dan) cevaplar benim için ilginç ve yararlı oldu!

— webaware

14

Çeviri için asla çekirdek dizelere güvenmeyin, istedikleri contextzaman parametre değiştirebilir veya alabilirler . Bu gerçekleştiğinde kullanıcılarınız kısmen çevrilmiş bir arayüze sahip olur ve çevirmenlerinizin bunu düzeltmesinin bir yolu yoktur.

Ayrıca aynı dize her yerde aynı kelime ile tercüme gerekli değildir unutmayın. Bağlam parametresi olmasa bile, bazı dillerde eklentiniz için farklı bir çeviri kullanmak yararlı olabilir. Ancak, dizeyi eklentinize eklemezseniz bu mümkün olmaz.

Bu konu hakkında birkaç gün önce yaptığımız sohbet tartışmalarına bakın .

— fuxia
kaynak

Ayrıca dizenin, metin alanı olmasa bile POT dosyanızda görüneceğini unutmayın.

— scribu

@ scribu Ayrıştırıcıya bağlıdır. Codestyling yerelleştirme eklentisi onu yok sayar.

— fuxia

Bu cevap ile neredeyse aynı soruya verilen cevap arasında bazı anlaşmazlıklar var gibi görünüyor ...

— mrwweb

4

Evet, ama lütfen yapma. Bu, kodlama standardı gibidir, atlayarak küçük bir avantaj elde edebiliyorsanız bile daha iyi takip edin.

Daha iyi nedenler:

Sürüm 3.5'te WordPress'in tek parça çeviri dosyaları yoktur, performans nedenleriyle 3 bölüme ayrılmıştır. Bu eğilim devam ederse, varsayılan etki alanının içinde kullanmaya çalıştığınızda yükleneceğinden emin olabilir misiniz __('Pages')?
Çalışmayı yerelleştiriciye kaydetmezsiniz - poedit gibi çeviri araçları, bir dosyada iki çeviri alanıyla nasıl başa çıkılacağını bilmez ve örneğinizde, "Sayfalar" kelimesini içeren bir .po dosyası oluştururlar. bunun için varsayılan etki alanını kullanın. Yerelleştirici, bağlamı anlaması gerekmediği sürece çevirdiği dizelerin gerçek kullanımını kontrol etmez, böylece farklı etki alanını fark etmeyecek ve kelimeyi çevirecektir. Ayrıca, yerelleştirici araçlarını biliyorsa, WordPress çekirdek çeviri dosyalarına dayalı bir çeviri DB'sine sahip olacak ve böylece poedit'in 'Sayfalar' gibi kelimeleri otomatik olarak çevirmesini sağlayacak.

— Mark Kaplun
kaynak

0

Deneyebilirsin

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

Veya

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');
});

Referans ： https://v123.tw/use-wordpress-core-translation/

İyi şanslar!!

— Ann
kaynak