Lokalizacja motywu „ślimaków” (niestandardowe typy postów, taksonomie)

w moim temacie chcę zdefiniować szereg niestandardowych typów postów i niestandardowych taksonomii, z których każdy ma swój własny dostosowany ślimak; podstawowym językiem mojego motywu jest angielski, dlatego ślimaki będą w języku angielskim

na przykład podczas definiowania informacji o niestandardowym typie postu „produkt” argumentuje:

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

czy jest jakiś sposób na przetłumaczenie „ślimaka” przez pliki po / mo? czy mogę to ująć jako:

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

czy to nie zadziała? jaka jest obecna praktyka lokalizowania ślimaków?

Nie próbowałbym zlokalizować twoich ślimaków. Zamiast tego dlaczego nie dać użytkownikom możliwości ich zmiany, dodając kolejne pole do strony ustawień łącza bezpośredniego?

Podłącz się load-options-permalink.phpi skonfiguruj kilka rzeczy, aby złapać $_POSTdane i zapisać swój ślimak. Dodaj także pole ustawień do strony.

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

Następnie funkcja oddzwaniania dla pola ustawień:

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

Następnie, gdy zarejestrujesz swój typ posta, złap za ślimak get_option. Jeśli go nie ma, użyj domyślnego.

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

Oto część pola ustawień jako wtyczka https://gist.github.com/1275867

EDYCJA: Kolejna opcja

Można również zmienić ślimak w oparciu o to, co zdefiniowano w WPLANG stałej.

Wystarczy napisać szybką funkcję, która przechowuje dane ...

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

Następnie weź ślimak, w którym rejestrujesz swój niestandardowy typ postu.

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

Najlepszą opcją, IMO, byłoby zarówno zaoferowanie użytkownikowi opcji, jak i zapewnienie stałych wartości domyślnych:

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

Jeśli to nie zadziała, to po prostu po prostu:

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

Robię dokładnie to, co rozwijamy. Jest dostępny w 5 różnych językach, a każdy język ma przetłumaczony zestaw kategorii. Pierwszy składnik adresu URL w kompozycji jest analizowany w celu ustalenia, który język jest używany, w formacie kraju:

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

Następnie przetłumaczone kategorie są analizowane jako dalsze elementy adresu URL.

Adres URL jest analizowany w parse_requestfazie:

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

Ten przykład jest pozbawiony wymaganych kontroli, ale ma jedynie charakter przykładowy.

Takie podejście ma oczywiście wady, ale pozwala na stosowanie naturalnych adresów URL we wszystkich językach. Główne wady, które widzę to:

1) Nie wykorzystuje mechanizmu permalink. Można by to prawdopodobnie rozszerzyć, tak aby generowane były odpowiednie reguły permalink dla wszystkich języków i parse_request nie byłby konieczny, ale zrobienie tego dla wszystkich języków wymagałoby załadowania jednego pliku MO po drugim w pętli, a ja nie wiedzieć, jak dobrze jest to obsługiwane.

2) Jeśli tłumacz zmieni ślimak, linki zostaną unieważnione.

Możesz spróbować tego w swoim 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;
});
?>

jak widać tutaj

Nie polecam, aby ślimaki były tłumaczalne .

Tłumaczenie dotyczy treści witryny przeznaczonych dla użytkowników . Informacje o ślimakach są używane wewnętrznie i są jedynie marginalnie „dostępne publicznie” poprzez przepisywanie adresów URL - adresy URL również nie powinny być tłumaczone .

Więc: zostaw ślimaki w spokoju, tak jak je definiujesz. Wykonuj tylko ciągi do tłumaczenia, które są przeznaczone do spożycia publicznego .