Themenlokalisierung von "Schnecken" (benutzerdefinierte Beitragstypen, Taxonomien)


16

In meinem Thema möchte ich eine Reihe von benutzerdefinierten Beitragstypen und Taxonomien definieren, von denen jeder seinen eigenen benutzerdefinierten Slug hat. Die Basissprache meines Themas ist Englisch, daher werden die Slugs in englischer Sprache sein

Zum Beispiel beim Definieren des Slugs von benutzerdefinierten Artikeln vom Typ "Produkt":

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

Gibt es eine Möglichkeit, die "Schnecke" durch PO / MO-Dateien zu übersetzen? kann ich sagen:

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

oder klappt es nicht Was ist die derzeitige Praxis, um Schnecken zu lokalisieren?


Ich weiß nicht, ob es sich um dasselbe Problem handelt, aber es scheint so. Zur besseren Veranschaulichung finden Sie hier einen Link zu einer ursprünglichen Indexseite für einen benutzerdefinierten Beitragstyp, der prensamit einem Slug-Set auf aufgerufen wird prensa. Unter Verwendung von WPML ist die Seite der Übersetzung so, presswie sie nicht mehr prensasein kann: / de / press / was nichts anzeigt (beachten Sie, dass Sie durch Klicken auf den ES-Link nicht zurück zu / prensa / gelangen). ABER, wenn Sie / de / prensa / besuchen, funktioniert es ...
Naoise Golden

Ich habe beschlossen, die Seiten von / en / press nach / en / prensa umzuleiten, damit der Link wahrscheinlich nicht mehr wie erwähnt funktioniert. Schade, dass ich den lokalisierten Slug nicht verwenden konnte, aber die Einarbeitungszeit ist besser als die URL-Lokalisierung
Naoise Golden,

Sehen Sie meine Antwort Naoise, ich denke, es wird Ihnen eine funktionierende Lösung geben.
Chrisguitarguy

Ich hatte stundenlang dieses Problem. Ich habe endlich einen Hack gefunden: github.com/stouch/wp-plugin-polylang-localized-taxonomy-slug/… Grüße.
Sylvain Tch

Antworten:


19

Ich würde nicht versuchen, Ihre Schnecken zu lokalisieren. Geben Sie Ihren Benutzern stattdessen die Möglichkeit, sie zu ändern, indem Sie der Seite mit den Permalink-Einstellungen ein weiteres Feld hinzufügen.

Schließen Sie sich an load-options-permalink.phpund richten Sie einige Dinge ein, um die $_POSTDaten zu erfassen und Ihre Schnecke zu retten. Fügen Sie der Seite auch ein Einstellungsfeld hinzu.

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

Dann die Rückruffunktion für das Einstellungsfeld:

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

Wenn Sie dann Ihren Beitragstyp registrieren, greifen Sie nach der Schnecke mit get_option. Wenn es nicht vorhanden ist, verwenden Sie Ihre Standardeinstellung.

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

Hier ist der Einstellungsfeldteil als Plugin https://gist.github.com/1275867

BEARBEITEN: Eine weitere Option

Sie können den Slug auch basierend auf den in der WPLANGKonstante definierten Werten ändern .

Schreiben Sie einfach eine schnelle Funktion, die Daten enthält ...

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

Holen Sie sich dann den Slug, auf dem Sie Ihren benutzerdefinierten Beitragstyp registrieren.

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

Die beste Option, IMO, wäre, dem Benutzer eine Option zu geben und solide Standardeinstellungen bereitzustellen:

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

2
+1 für das Plugin und den gut dokumentierten Code. In meinem Fall hat es jedoch den Zweck, dem Benutzer keine Macht zu geben , sondern lokalisierungsbezogene (SEO-freundliche) URLs für benutzerdefinierte Beitragstypen
Naoise Golden

1
Ich bin mir nicht sicher, warum Sie eine Option von Ihrem Benutzer entfernen möchten. Außerdem haben sie beim Durchlaufen eines Übersetzungsfilters die gleiche Möglichkeit: den Slug zu ändern. Nur nicht mit einem hübschen Formularfeld ausfüllen.
Chrisguitarguy

nur aus Neugier, warum wpse30021?
Naoise Golden

Es scheint, als ob diese Option für eine WPLANG-basierte Lokalisierung ist. Aber was ist, wenn Sie mit einer mehrsprachigen Site arbeiten? (zum Beispiel WPML-Plugin). Bei der Frage geht es mehr darum, je nach Lokalisierung des Clients einen anderen Slug anzuzeigen, als in den Serveroptionen einen benutzerdefinierten Slug-Typ für Posts festzulegen.
Naoise Golden

wpse = WordPress-Stapelaustausch. 30021 ist die Nummer aus der URL. Viel Glück bei Ihrer Suche; Ich habe meine Antwort gegeben. Aufgrund der zusätzlichen Komplexität, die Sie hinzufügen, und der offensichtlichen vollständigen Änderung der ursprünglichen Frage - ursprünglich zu CPT-Butzen - kann der Endbenutzer nur einen eigenen Butzen auswählen.
Chrisguitarguy

2

Wenn das nicht geht Warum gehst du nicht einfach so?

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

das hat bei mir nicht funktioniert
Naoise Golden

es ist im Grunde der gleiche Code in einem anderen Stil
Naoise Golden

Haben Sie die richtige Textdomäne hinzugefügt? <? php load_theme_textdomain (my_text_domain);?>?
Chifliiiii

Dies ist bei weitem die beste Lösung.
Al Rosado

2

Ich mache genau das in einem Thema, das wir entwickeln. Es ist in 5 verschiedenen Sprachen verfügbar und jede Sprache verfügt über einen übersetzten Satz von Kategorien. Die erste Komponente der URL im Design wird analysiert, um zu bestimmen, welche Sprache im Landessprachenformat verwendet wird:

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

Und dann werden übersetzte Kategorien als weitere Bestandteile der URL analysiert.

Die URL wird in der parse_requestPhase analysiert :

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

Dieses Beispiel enthält keine erforderlichen Überprüfungen, sondern dient nur als Beispiel.

Natürlich hat dieser Ansatz auch Nachteile, aber er ermöglicht natürliche URLs in allen Sprachen. Die Hauptnachteile, die ich sehe, sind:

1) Der Permalink-Mechanismus wird nicht verwendet. Dies könnte wahrscheinlich so erweitert werden, dass die richtigen Permalink-Regeln für alle Sprachen generiert werden und parse_request nicht erforderlich ist. Um dies jedoch für alle Sprachen zu tun, müsste eine MO-Datei nach der anderen in einer Schleife geladen werden, und ich nicht weiß wie gut das unterstützt wird.

2) Wenn ein Übersetzer einen Slug ändert, werden die Links ungültig.


0

Sie könnten dies in Ihrem versuchen 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;
});
?>

wie hier gesehen


-1

Ich würde empfehlen, keine Schnecken übersetzbar zu machen .

Die Übersetzung ist für benutzerbezogene Website-Inhalte vorgesehen . Slugs werden intern verwendet und sind über URL-Umschreibungen nur am Rande "öffentlich" - und URLs sollten auch nicht übersetzbar sein.

Also: Lass deine Schnecken in Ruhe, wie du sie definierst. Stellen Sie nur übersetzbare Zeichenfolgen her, die für den öffentlichen Gebrauch bestimmt sind .


11
Übersetzte Slugs, sowohl aus der SEO- als auch aus der User Experience-Perspektive, sind sehr sinnvoll ...
Naoise Golden

Ich bin nicht einverstanden, dass Slugs die Benutzererfahrung in irgendeiner Weise beeinflussen. Wenn ein Slug als Teil eines Links verwendet wird, wird der Linktext übersetzt, sodass der Benutzer den Unterschied nicht erkennt. Und wenn die Leute anfangen, sich mit "SEO" zu beschäftigen, denke ich im Allgemeinen " Schlangenöl ". Ich bin kein SEO-Experte, aber ich kaufe keine SEO-Auswirkungen in Bezug auf übersetzte Slugs.
Chip Bennett

3
Ich bin aufgrund meiner Erfahrung anderer Meinung. Wir haben intern ausländische Content-Manager, die ausdrücklich festlegen, dass URL-Slugs lokalisiert werden sollen. Es ist eine Frage der Schaffung einer vollständigen / vollständigen lokalen Erfahrung für den ausländischen Benutzer. In einigen Ländern wie Japan ist es im wahrsten Sinne des Wortes unerlässlich, ein authentisches Vertrauen aufzubauen und darauf hinzuweisen, dass es Ihnen wirklich ernst ist, dort Geschäfte zu machen.
Internetross

URLs müssen sprechen. Wenn der Slug also (so oft) der Name der Entität oder die Taxonomie ist, muss das Umschreiben sowohl Pluralformen als auch Übersetzungen berücksichtigen. Dies ist keine Option, sowohl für die Suchmaschinenoptimierung als auch für die gute Praxis gegenüber den Endbenutzern.
Luca Reghellin
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.