Ожидаемое поведение WPML, которое выглядит как проблема

Некоторые вещи на многоязычном сайте работают иначе по задумке: функция WordPress, привязанная к термину на языке по умолчанию, суффикс даты, который WordPress не может локализовать, слаг, который Расширенный редактор переводов не придумывает. В запросах в поддержку о них сообщают как об ошибках, но это не так. На этой странице рассказывается, что происходит, почему и что делать в таких случаях.

has_category() и другие условные теги в переведенных записях

Ядро WordPress has_category() намеренно не фильтруется WPML. В переводе категория — это переведенный термин, имеющий собственный слаг, поэтому has_category('news') возвращает false для французской записи, даже если она находится во французской категории «news». То же самое касается has_term(), in_category() и любого кода, который сравнивает слаг или ID термина на языке по умолчанию. Вызывайте условие с переведенным слагом или сначала определите ID термина с помощью фильтра wpml_object_id.

Что Вы видите

Стандартная функция WordPress has_category не работает для переведенных записей.

Пример выглядит следующим образом:

У нас есть категория с английским слагом «test» и ее французский перевод «test-fr».
Эта категория назначена записям.
Когда Вы вызываете has_category("test") внутри цикла в файле single.php Вашей темы оформления, функция возвращает true для языка по умолчанию, но false для перевода.

Что делать

Определите новый фильтр в файле functions.php Вашей темы оформления:

function wp_has_category ($category) {
$category = get_term_by('name', $category, 'category');
return has_category($category);
}
add_filter('wp_has_category', 'wp_has_category', 10, 1);

Замените функцию has_category на этот новый фильтр:

apply_filters( 'wp_has_category', 'test' )

Этот фильтр берет переведенную категорию на основе названия оригинальной и проверяет, назначена ли переведенная категория записи.

Справка: wpmlcore-3024.

Суффиксы дат (1st, 2nd, 3rd) не переводятся

Это ограничение ядра WordPress, а не WPML: суффикс берется из форматирования дат PHP и никогда не проходит через функцию перевода.

Что Вы видите

Некоторые темы оформления или плагины используют функции WordPress wp_date() или date_i18n() для отображения дат. В этих датах может использоваться суффикс, например, 1st или 26th, в зависимости от выбранных параметров.

В настоящее время перевести суффиксы дат невозможно из-за давнего известного ограничения в ядре WordPress.

Что делать

В качестве обходного решения Вы можете использовать фильтр wp_date для получения даты, а затем изменить суффикс перед его выводом на странице. Пожалуйста, сделайте полную резервную копию Вашего сайта перед тем, как продолжить, и выполните следующие действия:

Добавьте небольшой фильтр wp_date в файл functions.php Вашей темы оформления, который регистрирует каждый суффикс как строку (icl_register_string) и возвращает ее перевод (icl_t) вместо английского суффикса:

Откройте страницу, на которой отображаются даты. Это приведет к выполнению добавленного фильтра.

Перейдите в WPML → Перевод строк и переведите даты.

Вам нужно будет перевести каждый суффикс отдельно (например, 1st, 2nd...), поскольку он может меняться в зависимости от языка.

Справка: compsupp-5773.

Расширенный редактор переводов не придумывает слаг

Редактор переводит поле слага, когда Вы его заполняете, и сохраняет оригинальный слаг, когда Вы оставляете его пустым. Он никогда не образует слаг от переведенного заголовка самостоятельно.

Что Вы видите

Если Вы переводите запись с помощью нашего Расширенного редактора переводов, поле слага не заполняется автоматически. Если затем Вы решите оставить поле слага пустым, в переведенную запись загрузится слаг на языке оригинала.

Справка: wpmlsupp-8574.

Шорткоды конструкторов страниц в кратком описании товара WooCommerce

Краткое описание — это отрывок записи (excerpt), который по определению WordPress является полем обычного текста, поэтому WPML не обрабатывает в нем шорткоды конструкторов страниц так, как делает это в контенте. WooCommerce, однако, отображает их, из-за чего это несоответствие вызывает удивление.

Что Вы видите

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

Но WC обрабатывает эти «отрывки» немного иначе, и шорткоды действительно работают, однако WPML по-прежнему ведет себя так, будто они не работают. И если шорткод включает атрибуты, требующие перевода, или внутренние ссылки, которые должны обрабатываться автоматически, это становится невозможным без дополнительных действий.

Что делать

Мы подготовили код, который можно добавить в качестве плагина для реализации этого функционала. Скопируйте и вставьте приведенный ниже код в файл, который Вы можете назвать wpmlpb-excerpts.php, сохраните его в каталоге wp-content/plugins/, а затем активируйте плагин.

<?php
/**
 * Plugin Name: WPML Page Builders - Proces Excerpts
 * Description: Parses shortcode strings in exceprts.
 * Version: 1.0
 */
namespace WPMLPB686;

( new Excerpts() )->add_hooks();

class Excerpts {

	const SEPARATOR_START = '<!--WPML_EXCERPT_START-->';
	const SEPARATOR_END   = '<!--WPML_EXCERPT_END-->';

	public function add_hooks() {
		add_filter( 'wpml_pb_shortcode_content_for_translation', [ $this, 'joinWithContent' ], 10, 2 );
		add_filter( 'wpml_tm_translation_job_data', [ $this, 'excludeFromJob' ], 10, 2 );
		add_action( 'wpml_pro_translation_completed', [ $this, 'splitFromContent' ], 999 );
	}

	public function joinWithContent( $content, $id ) {
		$post = get_post( $id );
		if ( $post && $post->post_excerpt ) {
			$content .= self::SEPARATOR_START . $post->post_excerpt . self::SEPARATOR_END;
		}

		return $content;
	}

	public function excludeFromJob( $package, $post ) {
		if ( preg_match( '/[[^]]+]/', $post->post_excerpt ) ) {
			$package['contents']['excerpt']['translate'] = 0;
			$package['contents']['excerpt']['data']      = '';
		}

		return $package;
	}

	public function splitFromContent( $post_id ) {
		$post = get_post( $post_id );
		if ( $post && false !== strpos( $post->post_content, self::SEPARATOR_START ) ) {
			$start_pos = strpos( $post->post_content, self::SEPARATOR_START );
			$end_pos   = strpos( $post->post_content, self::SEPARATOR_END, $start_pos );

			if ( false !== $end_pos ) {
				$content = substr( $post->post_content, 0, $start_pos );
				$excerpt = substr( $post->post_content, $start_pos + strlen( self::SEPARATOR_START ), $end_pos - $start_pos - strlen( self::SEPARATOR_START ) );

				if ( $excerpt ) {
					wp_update_post(
						[
							'ID'           => $post_id,
							'post_content' => $content,
							'post_excerpt' => $excerpt,
						]
					);
				}
			}
		}
	}
}

Справка: wpmlpb-686.

Свой домен для каждого языка на хостинге WordPress.com

WordPress.com привязывает один домен к одному сайту; формату URL «свой домен для каждого языка» необходимо, чтобы домен каждого языка вел к одной и той же установке WordPress, чего этот хостинг не предлагает.

Что Вы видите

Из-за ограничений в работе привязки доменов на WordPress.com невозможно выбрать настройку URL языков для использования своего домена для каждого языка, если сайты размещены на этом хостинге.

Что делать

Вместо своего домена для каждого языка можно использовать любой из других вариантов URL языков: «Разные языки в каталогах» или «Название языка добавлено в качестве параметра».

Если использование своего домена для каждого языка является обязательным требованием, потребуется другой хостинг.

Справка: wpmltriage-2045.

Импортированные переводы и редакторы переводов

Импорт записывает готовые переводы; он не создает задания на перевод, а редакторы работают именно с заданиями. На фронтенде переводы являются завершенными, и их просто нельзя изменить в Расширенном или Классическом редакторе переводов.

Что Вы видите

При импорте контента с помощью WP All Import и дополнения WPML All Import Вы будете отлично видеть импортированные переводы записей на фронтенде. Однако Вы столкнетесь с проблемами, если попытаетесь обновить их с помощью редакторов переводов WPML:

Классический редактор переводов отображает контент на языке по умолчанию вместо импортированных переводов
Расширенный редактор переводов отображает пустые переводы

Это происходит потому, что при импорте многоязычного контента WPML не создает задания на перевод, которые необходимы для сегментации строк.

Что делать

Чтобы изменить или обновить импортированные переводы, пожалуйста, переключитесь на стандартный редактор WordPress и используйте ручной перевод.

Справка: WPMLAI-168.