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

17

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

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

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

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

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

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

unfulvio
источник
Я не знаю, имеем ли мы дело с той же проблемой, но похоже, что так. Чтобы лучше проиллюстрировать это, здесь есть ссылка на оригинальную страницу индекса для пользовательского типа записи, которая называется prensaslug prensa. Используя WPML, переведенный слаг страницы будет таким, pressкаким он не может быть prensaснова: / en / press /, который ничего не отображает (обратите внимание, что теперь щелкнув ссылку ES, вы не вернетесь к / prensa /). НО, если вы посещаете / en / prensa / это работает ...
Naoise Golden 10.10.11
Я решил перенаправить страницы из / en / press в / en / prensa, чтобы ссылка, вероятно, не работала, как уже упоминалось Жаль, что я не смог использовать локализованный слаг, но время работы лучше, чем дружественная к локализации URL
Naoise Golden 10.10.11
Смотрите мой ответ, Наойс, я думаю, что это даст вам рабочее решение.
chrisguitarguy
У меня была эта проблема часами. Я наконец нашел взлом: github.com/stouch/wp-plugin-polylang-localized-taxonomy-slug/… С уважением.
Сильвен

Ответы:

19

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

Подключитесь 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 );
}
chrisguitarguy
источник
2
+1 за плагин в сущности и хорошо документированный код. В моем случае, однако, это противоречит цели, которая состоит не в том, чтобы дать пользователю власть, а в том, чтобы сделать
учитывающие
1
Я не уверен, что понимаю, почему вы хотите удалить опцию из вашего пользователя. Более того, запуск слага через фильтр перевода дает им такую ​​же возможность: изменить слаг. Только не с красивым полем формы для заполнения.
chrisguitarguy
1
просто для любопытства, почему wpse30021?
Наоис Голден
Кажется, как будто эта опция для локализации на основе WPLANG. Но что, если вы работаете с многоязычным сайтом? (например, плагин WPML). Вопрос больше в том, чтобы отобразить другой слаг в зависимости от локализации клиента, чем возможность установить слаг собственного типа поста из опций сервера.
Наоис Голден
wpse = обмен стеками WordPress. 30021 - это номер из URL. Удачи в вашем квесте; Я дал свой ответ. Дополнительная сложность, которую вы добавляете, и очевидное полное изменение первоначального вопроса - первоначально о слизняках CPT, только дает возможность конечному пользователю выбрать своего собственного слага.
chrisguitarguy
2

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

$post_slug=  __('product', 'mytextdomain');
'rewrite' => array( 'slug' => $post_slug );
chifliiiii
источник
это не сработало для меня
Наоис Голден
это в основном тот же код в другом стиле
Naoise Golden 10.10.11
Вы добавили правильный текстовый домен? <? php load_theme_textdomain (my_text_domain);?>?
Чифлийии
Это, безусловно, лучшее решение.
Аль Росадо
2

Я делаю именно это в теме, которую мы развиваем. Он доступен на 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) Если переводчик меняет слаг, ссылки становятся недействительными.

Bendoh
источник
0

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

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

Младший М
источник
-1

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

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

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

Чип Беннетт
источник
11
переведенные слизни, как с точки зрения seo, так и с точки зрения пользовательского опыта, имеют большой смысл ...
Naoise Golden
Я не согласен с тем, что слизни влияют на пользовательский опыт в любом случае. Если слаг используется как часть ссылки, текст привязки ссылки будет переведен, поэтому пользователь не будет знать разницу. И когда люди начинают швырять вокруг «SEO», я обычно думаю, « змеиное масло ». Я не эксперт по SEO, но я не покупаю влияние SEO в отношении переведенных слагов.
Чип Беннетт
3
Я не согласен, основываясь на опыте. У нас есть сторонние менеджеры по контенту, которые явно указывают, что URL-слагы должны быть локализованы. Это вопрос создания полного локального опыта для иностранного пользователя. Для некоторых стран, таких как Япония, буквально необходимо установить подлинное доверие и указать, что вы действительно серьезно относитесь к ведению там бизнеса.
Интернет
URL должны говорить. Таким образом, если слаг - это (как часто) название организации или таксономии, при переписывании должны учитываться множественное число, а также переводы. Это не вариант, как для SEO, так и для просто хорошей практики для конечных пользователей.
Лука Регеллин