Тематическая локализация «слизней» (пользовательские типы постов, таксономии)

в моей теме я хочу определить серию пользовательских типов записей и пользовательских таксономий, каждая из которых имеет свой собственный настроенный слаг; базовый язык моей темы - английский, поэтому слизни будут на английском языке

например, при определении слага для пользовательских аргументов типа «product»:

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

есть ли способ перевести "слаг" через файлы po / mo? Могу ли я выразить это как:

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

или это не сработает? какова текущая практика локализации слизней?

Я бы не пытался локализовать ваши слизни. Вместо этого, почему бы не дать своим пользователям возможность изменить их, добавив другое поле на страницу настроек постоянной ссылки?

Подключитесь load-options-permalink.phpи настройте некоторые вещи, чтобы поймать $_POSTданные, чтобы сохранить ваш слаг. Также добавьте поле настроек на страницу.

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

Затем функция обратного вызова для поля настроек:

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

Затем, когда вы зарегистрируете свой тип поста, возьмите слаг get_option. Если его там нет, используйте ваш по умолчанию.

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

Вот часть поля настроек в виде плагина https://gist.github.com/1275867

РЕДАКТИРОВАТЬ: еще один вариант

Вы также можете изменить слаг в зависимости от того, что определено в WPLANGконстанте.

Просто напишите быструю функцию, которая хранит данные ...

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

Затем получите слаг, где вы зарегистрируете свой собственный тип записи.

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

Наилучшим вариантом, IMO, было бы предоставить пользователю возможность и предоставить твердые значения по умолчанию:

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

Если это не работает Почему бы вам просто не сделать:

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

Я делаю именно это в теме, которую мы развиваем. Он доступен на 5 разных языках, и каждый язык имеет переведенный набор категорий. Первый компонент URL-адреса в теме анализируется для определения используемого языка в формате страны:

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

А затем переведенные категории анализируются как дополнительные компоненты URL.

URL анализируется на parse_requestэтапе:

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

Этот пример лишен обязательных проверок, но подразумевается только как пример.

Конечно, у этого подхода есть недостатки, но он позволяет использовать естественные URL-адреса на всех языках. Основные недостатки, которые я вижу:

1) Он не использует механизм постоянных ссылок. Скорее всего, это можно расширить, чтобы сгенерировать правильные правила постоянной ссылки для всех языков, и parse_request не понадобится, но чтобы сделать это для всех языков, потребовалась бы загрузка одного MO-файла за другим в цикле, а я этого не делаю. знаю, насколько хорошо это поддерживается.

2) Если переводчик меняет слаг, ссылки становятся недействительными.

Вы можете попробовать это в своем 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;
});
?>

как видно здесь

Я бы порекомендовал не делать слизняков переводимыми .

Перевод для пользовательского контента сайта . Слагги используются внутри и только незначительно «общедоступны» при переписывании URL-адресов, и URL-адреса также не должны переводиться .

Итак: оставьте свои слизни в покое, как вы их определяете. Делайте только переводные струны, которые предназначены для общественного потребления .