Тематична локалізація "шлаків" (користувацькі типи публікацій, таксономії)

в моїй темі я хочу визначити серію користувацьких типів публікацій та користувальницьких таксономій, у кожної з яких є власний спеціалізований слуг; Основна мова моєї теми - англійська, тому шлаки будуть англійською мовою

наприклад, визначаючи слупок аргументів користувацького типу типу "продукт":

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

чи є якийсь спосіб перевести "slug" через 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

EDIT: Ще один варіант

Ви також можете змінити слизу на основі того, що визначено в 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-адреси також не повинні бути перекладними .

Отже: залиште своїх слимаків у спокої, як їх визначаєте. Робіть лише перекладні рядки, призначені для громадського споживання .