Posso interrompere il plugin textdomain per i termini utilizzati nel core?

10

Ho un plugin che mette gli stati dei post nei menu di amministrazione del tipo di post. Sono nel mezzo dell'internazionalizzazione e mi chiedo come gestire questa situazione.

Il plugin utilizza alcune stringhe uniche che otterranno un dominio di testo come questo:

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

Ma poi ci sono anche casi in cui sto usando una parola di base legati per il loro significato core-correlate come questo: __( 'Pages' ). In questa situazione, sembra perfettamente logico escludere il dominio di testo e sfruttare i termini che sono già localizzati nel nucleo. Tuttavia, il codice sembra molto esplicito:

Se stai cercando di tradurre un plug-in, valgono gli stessi consigli di cui sopra, tranne quello

devi usare un dominio, che viene caricato in un hook del tuo plugin

ogni chiamata di traduzione deve diventare __ ('text', 'domain-name')

Quindi è questo WP-kosher?

plugins localization

— mrwweb
fonte

1

Grazie per aver posto una domanda stimolante, le risposte (da Toscho e Mark Kaplun finora) sono state interessanti e utili per me!

— webaware il

14

Non fare mai affidamento sulle stringhe di base per la traduzione, possono cambiare o ottenere un contextparametro in qualsiasi momento. Una volta che ciò accade, i tuoi utenti ottengono un'interfaccia parzialmente tradotta e i tuoi traduttori non hanno modo di risolverlo.

Ricorda inoltre che la stessa stringa non è necessaria tradotta ovunque con la stessa parola. Anche senza un parametro di contesto potrebbe essere utile utilizzare una traduzione diversa per il tuo plugin in alcune lingue. Ma questo non sarebbe possibile se non includessi la stringa nel tuo plugin.

Vedi questa discussione di chat che abbiamo avuto alcuni giorni fa su questo argomento.

— fuxia
fonte

Tieni inoltre presente che la stringa verrà comunque visualizzata nel tuo file POT, anche se non ha un dominio di testo.

— scribu,

@scribu Dipende dal parser. Il plug-in di localizzazione del codestyling lo ignorerà.

— fuxia

Sembra che ci sia un certo disaccordo tra questa risposta e questa risposta su una domanda quasi identica ...

— mrwweb

4

Sì, ma per favore no. Questo è come lo standard di codifica, seguilo meglio anche quando puoi ottenere un piccolo vantaggio bypassandolo.

Ragioni migliori:

Nella versione 3.5 WordPress non ha un file di traduzione monolite, è stato suddiviso in 3 parti per motivi di prestazioni. Se questa tendenza continua, puoi essere sicuro che il dominio predefinito verrà caricato quando provi a utilizzarlo __('Pages')?
Non risparmierai lavoro nel localizzatore - Gli strumenti di traduzione come poedit non sanno come gestire due domini di traduzione in un unico file e nel tuo esempio genereranno un file .po che contiene la parola "Pagine" anche se tu usa il dominio predefinito per questo. Il localizzatore non controlla l'uso effettivo delle stringhe che traduce a meno che non abbia bisogno di capire il contesto, quindi non noterà il diverso dominio e tradurrà la parola. Inoltre, se il localizzatore conosce i suoi strumenti, avrà un DB di traduzione basato sui file di traduzione core di WordPress in un modo che consente a poedit di tradurre automaticamente parole come "Pagine".

— Mark Kaplun
fonte

0

Puoi provarlo

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

O

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

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

In bocca al lupo!!

— Ann
fonte