Localizzazione tematica di "lumache" (tipi di post personalizzati, tassonomie)

nel mio tema voglio definire una serie di tipi di post personalizzati e tassonomie personalizzate, ognuna con la propria lumaca personalizzata; la lingua di base del mio tema è l'inglese, quindi le lumache saranno in lingua inglese

ad esempio durante la definizione della lumaca del tipo di post personalizzato "product" args:

'rewrite' => array( 'slug' => 'product' ),

c'è un modo per tradurre lo "slug" attraverso i file po / mo? posso metterlo come:

'rewrite' => array( 'slug' => __('product', 'mytextdomain') )

o non funzionerà? qual è la pratica corrente per localizzare le lumache?

Non proverei a localizzare le tue lumache. Invece, perché non dare ai tuoi utenti la possibilità di cambiarli aggiungendo un altro campo alla pagina delle impostazioni del permalink?

Aggancia load-options-permalink.phpe imposta alcune cose per catturare i $_POSTdati per salvare la tua lumaca. Aggiungi anche un campo impostazioni alla pagina.

<?php
add_action( 'load-options-permalink.php', 'wpse30021_load_permalinks' );
function wpse30021_load_permalinks()
{
    if( isset( $_POST['wpse30021_cpt_base'] ) )
    {
        update_option( 'wpse30021_cpt_base', sanitize_title_with_dashes( $_POST['wpse30021_cpt_base'] ) );
    }

    // Add a settings field to the permalink page
    add_settings_field( 'wpse30021_cpt_base', __( 'CPT Base' ), 'wpse30021_field_callback', 'permalink', 'optional' );
}

Quindi la funzione di richiamata per il campo delle impostazioni:

<?php
function wpse30021_field_callback()
{
    $value = get_option( 'wpse30021_cpt_base' );    
    echo '<input type="text" value="' . esc_attr( $value ) . '" name="wpse30021_cpt_base" id="wpse30021_cpt_base" class="regular-text" />';
}

Quindi quando registri il tuo tipo di post, prendi la lumaca con get_option. Se non è presente, utilizza l'impostazione predefinita.

<?php
add_action( 'init', 'wpse30021_register_post_type' );
function wpse30021_register_post_type()
{
    $slug = get_option( 'wpse30021_cpt_base' );
    if( ! $slug ) $slug = 'your-default-slug';

    // register your post type, reference $slug for the rewrite
    $args['rewrite'] = array( 'slug' => $slug );

    // Obviously you probably need more $args than one....
    register_post_type( 'wpse30021_pt', $args );
}

Ecco la parte del campo delle impostazioni come plugin https://gist.github.com/1275867

EDIT: un'altra opzione

Puoi anche cambiare la lumaca in base a ciò che è definito in WPLANG costante.

Basta scrivere una funzione rapida che contiene i dati ...

<?php
function wpse30021_get_slug()
{
    // return a default slug
    if( ! defined( 'WPLANG' ) || ! WPLANG || 'en_US' == WPLANG ) return 'press';

    // array of slug data
    $slugs = array( 
        'fr_FR' => 'presse',
        'es_ES' => 'prensa'
        // etc.
    );

    return $slugs[WPLANG];
}

Quindi prendi la lumaca dove registri il tuo tipo di post personalizzato.

<?php
add_action( 'init', 'wpse30021_register_post_type' );
function wpse30021_register_post_type()
{
    $slug = wpse30021_get_slug();

    // register your post type, reference $slug for the rewrite
    $args['rewrite'] = array( 'slug' => $slug );

    // Obviously you probably need more $args than one....
    register_post_type( 'wpse30021_pt', $args );
}

L'opzione migliore, IMO, sarebbe quella di dare all'utente un'opzione e fornire solide impostazioni predefinite:

<?php
add_action( 'init', 'wpse30021_register_post_type' );
function wpse30021_register_post_type()
{
    $slug = get_option( 'wpse30021_cpt_base' );
    // They didn't set up an option, get the default
    if( ! $slug ) $slug = wpse30021_get_slug();

    // register your post type, reference $slug for the rewrite
    $args['rewrite'] = array( 'slug' => $slug );

    // Obviously you probably need more $args than one....
    register_post_type( 'wpse30021_pt', $args );
}

Se quello non funziona Perché non fai semplicemente:

$post_slug=  __('product', 'mytextdomain');
'rewrite' => array( 'slug' => $post_slug );

Lo sto facendo esattamente in un tema che stiamo sviluppando. È disponibile in 5 lingue distinte e ogni lingua ha un insieme tradotto di categorie. Il primo componente dell'URL nel tema viene analizzato per determinare la lingua utilizzata, nel formato lingua del paese:

/uk-en
/fr-fr
/it-it

E quindi le categorie tradotte vengono analizzate come ulteriori componenti dell'URL.

L'URL viene analizzato nella parse_requestfase:

function my_parse_request( $wp ) {
    $path = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );

    $components = preg_split('|/|', $path, null, PREG_SPLIT_NO_EMPTY );

    // Determine language from $components[0]
    $language = array_shift( $components );
    ...

    // Load translations file...
    $mofile = get_stylesheet_directory()."/$language.mo";

    load_textdomain( 'mydomain', $mofile );

    ...

    // Determine category from $components[0]
    if( __( 'some-category', 'mydomain' ) == $components[0] )
      $wp->query_vars['category'] = 'some-category';

    ...
}
add_action( 'parse_request', 'my_parse_request' );

Questo esempio è privo di controlli necessari, ma è inteso solo come esempio.

Ci sono svantaggi di questo approccio, ovviamente, ma consente URL naturali in tutte le lingue. I principali svantaggi che vedo sono:

1) Non utilizza il meccanismo permalink. Questo potrebbe probabilmente essere esteso in modo da generare le regole di permalink appropriate per tutte le lingue e non sarà necessario parse_request, ma farlo per tutte le lingue implicherebbe il caricamento di un file MO dopo l'altro in un ciclo, e io no sapere quanto è ben supportato.

2) Se un traduttore cambia una lumaca, i collegamenti vengono invalidati.

Potresti provare questo nel tuo functions.php

<?php
add_filter('rewrite_slugs', function($translated_slugs) {
    // the possible translations for your slug 'product'
    $translated_slugs = array(
        'product' => array(
            'pt' => array(
                'has_archive' => true,'rewrite' => array('slug' => 'produto'),
            ),
            'es' => array(
                'has_archive' => true,'rewrite' => array('slug' => 'producto'),
            ),
        ),
    );
    return $translated_slugs;
});
?>

come visto qui

Consiglierei di non rendere traducibili le lumache .

La traduzione è per il contenuto del sito rivolto all'utente . Le lumache sono utilizzate internamente e sono solo marginalmente "rivolte al pubblico" tramite riscritture di URL - e gli URL non devono essere traducibili .

Quindi: lascia in pace le tue lumache, come le definisci. Crea solo stringhe traducibili destinate al consumo pubblico .