Localisation thématique des «slugs» (types de messages personnalisés, taxonomies)

dans mon thème, je veux définir une série de types de messages personnalisés et de taxonomies personnalisées, chacun ayant son propre slug personnalisé; la langue de base de mon thème est l'anglais, donc les slugs seront en anglais

par exemple, lors de la définition du slug d'arguments de type de produit personnalisé "produit":

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

existe-t-il un moyen de traduire le "slug" à travers des fichiers po / mo? puis-je le dire comme:

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

ou ça ne marchera pas? quelle est la pratique actuelle pour localiser les limaces?

Je n'essaierais pas de localiser tes limaces. Au lieu de cela, pourquoi ne pas donner à vos utilisateurs la possibilité de les modifier en ajoutant un autre champ à la page des paramètres de permalien?

Accrochez-vous load-options-permalink.phpet configurez certaines choses pour attraper les $_POSTdonnées pour enregistrer votre limace. Ajoutez également un champ de paramètres à la page.

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

Ensuite, la fonction de rappel pour le champ des paramètres:

<?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" />';
}

Ensuite, lorsque vous enregistrez votre type de publication, saisissez le slug avec get_option. Si ce n'est pas le cas, utilisez votre valeur par défaut.

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

Voici la partie du champ des paramètres en tant que plugin https://gist.github.com/1275867

EDIT: une autre option

Vous pouvez également modifier le slug en fonction de ce qui est défini dans la WPLANGconstante.

Écrivez simplement une fonction rapide qui contient des données ...

<?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];
}

Obtenez ensuite le slug où vous enregistrez votre type de publication personnalisé.

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

La meilleure option, l'OMI, serait à la fois de donner à l'utilisateur une option et de fournir des valeurs par défaut solides:

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

Si cela ne fonctionne pas, pourquoi ne pas simplement faire:

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

C'est exactement ce que je fais dans un thème que nous développons. Il est disponible en 5 langues distinctes, et chaque langue a un ensemble traduit de catégories. Le premier composant de l'URL dans le thème est analysé pour déterminer la langue utilisée, au format de la langue du pays:

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

Et puis les catégories traduites sont analysées en tant que composants supplémentaires de l'URL.

L'URL est analysée dans la parse_requestphase:

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

Cet exemple est dépourvu des vérifications requises, mais n'est donné qu'à titre d'exemple.

Cette approche présente certes des inconvénients, mais elle autorise les URL naturelles dans toutes les langues. Les principaux inconvénients que je vois sont:

1) Il n'utilise pas le mécanisme de permalien. Cela pourrait probablement être étendu afin que les règles de permalien appropriées pour toutes les langues soient générées et que parse_request ne soit pas nécessaire, mais le faire pour toutes les langues impliquerait de charger un fichier MO après l'autre dans une boucle, et je ne le fais pas savoir à quel point cela est bien soutenu.

2) Si un traducteur change un slug, alors les liens sont invalidés.

Vous pouvez essayer ceci dans votre 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;
});
?>

comme on le voit ici

Je recommanderais de ne pas rendre les limaces traduisibles .

La traduction concerne le contenu du site accessible aux utilisateurs . Les limaces sont utilisées en interne et ne sont que marginalement accessibles au public via des réécritures d'URL - et les URL ne doivent pas non plus être traduisibles .

Alors: laissez vos limaces tranquilles, comme vous les définissez. Faites uniquement des chaînes traduisibles qui sont destinées à la consommation publique .