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

17

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?

unfulvio
la source
Je ne sais pas si nous avons affaire au même problème, mais il semble que ce soit le cas. Pour mieux l'illustrer, voici un lien vers une page d' index d' origine pour un type de publication personnalisé appelé prensaavec un slug défini sur prensa. En utilisant WPML, le slug de la page traduite est presstel qu'il ne peut plus être prensa: / en / press / qui n'affiche rien (notez que maintenant cliquer sur le lien ES ne vous ramène pas à / prensa /). MAIS, si vous visitez / en / prensa / ça marche ...
Naoise Golden
J'ai décidé de rediriger les pages de / en / press vers / en / prensa donc le lien ne fonctionnera probablement plus comme mentionné. Dommage que je ne puisse pas utiliser le slug localisé, mais travailler à l'heure est préférable à la localisation par URL
Naoise Golden
Voir ma réponse Naoise, je pense que cela vous donnera une solution de travail.
chrisguitarguy
J'ai eu ce problème pendant des heures. J'ai finalement trouvé un hack: github.com/stouch/wp-plugin-polylang-localized-taxonomy-slug/… Cordialement.
Sylvain Tch

Réponses:

19

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 );
}
chrisguitarguy
la source
2
+1 pour le plugin sur gist et le code bien documenté. Dans mon cas, cependant, cela va à l'encontre du but, qui n'est pas de donner le pouvoir à l'utilisateur, mais de créer des URL sensibles à la localisation (optimisées pour les moteurs de recherche) pour les types de publication personnalisés
Naoise Golden
1
Je ne suis pas sûr de comprendre pourquoi vous souhaitez supprimer une option de votre utilisateur. De plus, l'exécution d'un slug à travers un filtre de traduction leur donne la même option: changer le slug. Mais pas avec un joli champ de formulaire à remplir.
chrisguitarguy
1
juste pour la curiosité, pourquoi wpse30021?
Naoise Golden
Il semble que cette option soit pour une localisation basée sur WPLANG. Mais que faire si vous travaillez avec un site multilingue? (par exemple plugin WPML). La question concerne plus l'affichage d'un slug différent en fonction de la localisation du client que la possibilité de définir un slug de type de publication personnalisé à partir des options du serveur.
Naoise Golden
wpse = échange de pile WordPress. 30021 est le numéro de l'URL. Bonne chance dans votre quête; J'ai donné ma réponse. La complexité supplémentaire que vous ajoutez et le changement complet apparent de la question d'origine - à l'origine sur les limaces CPT, ne font que permettre à l'utilisateur final de choisir sa propre limace.
chrisguitarguy
2

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

$post_slug=  __('product', 'mytextdomain');
'rewrite' => array( 'slug' => $post_slug );
chifliiiii
la source
cela n'a pas fonctionné pour moi
Naoise Golden
c'est fondamentalement le même code dans un autre style
Naoise Golden
Avez-vous ajouté le domaine de texte approprié? <? php load_theme_textdomain (my_text_domain);?>?
chifliiiii
C'est de loin la meilleure solution.
Al Rosado
2

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.

Bendoh
la source
0

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

Junior M
la source
-1

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 .

Chip Bennett
la source
11
les slugs traduits, tant du point de vue du référencement que de l'expérience utilisateur, ont beaucoup de sens ...
Naoise Golden
Je ne suis pas d'accord que les limaces aient un impact sur l'expérience utilisateur de quelque façon que ce soit. Si un slug est utilisé dans le cadre d'un lien, le texte d'ancrage du lien sera traduit, de sorte que l'utilisateur ne connaîtra pas la différence. Et quand les gens commencent à tourner autour du "SEO", je pense généralement, "l' huile de serpent ". Je ne suis pas un expert SEO, mais je n'achète pas d'impact SEO en ce qui concerne les slugs traduits.
Chip Bennett
3
Je ne suis pas d'accord sur la base de l'expérience. Nous avons en interne des gestionnaires de contenu étrangers qui expliquent que les slugs d'URL doivent être localisés. Il s'agit de créer une expérience locale complète / ly pour l'utilisateur étranger. Pour certains pays, comme le Japon, il est littéralement essentiel d'établir une sorte de confiance authentique et d'indiquer que vous êtes vraiment sérieux au sujet de faire des affaires là-bas.
internetross
les URL doivent parler. Donc si le slug est (comme souvent) le nom de l'entité ou de la taxonomie, la réécriture doit prendre en compte les pluriels ainsi que les traductions. Ce n'est pas une option, à la fois pour le référencement et simplement pour les utilisateurs finaux.
Luca Reghellin