Comportements attendus de WPML qui peuvent ressembler à des anomalies

Certaines choses fonctionnent différemment sur un site multilingue par conception : une fonction WordPress basée sur un terme de la langue par défaut, un suffixe de date que WordPress ne peut pas localiser, un slug que l’Éditeur de traduction avancé n’invente pas. Les demandes d’assistance les signalent comme des bogues ; ce n’est pas le cas. Cette page explique ce qui se passe, pourquoi et ce qu’il faut faire à la place.

has_category() et autres balises conditionnelles sur les articles traduits

Le noyau de WordPress ne filtre pas has_category() par l’intermédiaire de WPML, et ce, délibérément. Sur une traduction, la catégorie est le terme traduit, qui a son propre slug, donc has_category('news') est faux sur l’article en français même si l’article en français se trouve dans la catégorie française « news ». Il en va de même pour has_term(), in_category() et tout code qui compare un slug ou un ID de terme de la langue par défaut. Appelez la conditionnelle avec le slug traduit, ou résolvez d’abord l’ID de terme via le filtre wpml_object_id.

Ce que vous voyez

La fonction native de WordPress has_category ne fonctionne pas pour les articles traduits.

En voici un exemple :

1. Nous avons une catégorie avec le slug anglais « test » et sa traduction française « test-fr ».
2. Cette catégorie est attribuée à des articles.
3. Lorsque vous invoquez has_category("test") dans une boucle du fichier single.php de votre thème, il renvoie true pour la langue par défaut, mais false pour la traduction.

Ce qu’il faut faire

Définissez un nouveau filtre dans le fichier functions.php de votre thème :

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

Remplacez la fonction has_category par ce nouveau filtre :

apply_filters( 'wp_has_category', 'test' )

Ce filtre prend la catégorie traduite en fonction du nom de la catégorie d’origine et vérifie si la catégorie traduite est attribuée à un article.

Référence : wpmlcore-3024.

Les suffixes de date (1st, 2nd, 3rd) ne sont pas traduisibles

Il s’agit d’une limitation du noyau de WordPress, et non de WPML : le suffixe provient du formatage de date de PHP et ne passe jamais par une fonction de traduction.

Ce que vous voyez

Certains thèmes ou extensions utilisent les fonctions WordPress wp_date() ou date_i18n() pour afficher les dates. Ces dates peuvent utiliser un suffixe comme 1st ou 26th, selon les paramètres sélectionnés.

Actuellement, il n’est pas possible de traduire les suffixes de date en raison d’une limitation connue de longue date dans le noyau de WordPress.

Ce qu’il faut faire

Comme solution de contournement, vous pouvez utiliser le filtre wp_date pour obtenir la date, puis modifier le suffixe avant qu’il ne soit affiché sur la page. Veuillez effectuer une sauvegarde complète de votre site avant de continuer et suivez les étapes ci-dessous :

• Ajoutez un petit filtre wp_date au fichier functions.php de votre thème qui enregistre chaque suffixe comme une chaîne de texte (icl_register_string) et renvoie sa traduction (icl_t) à la place du suffixe anglais :


• Ouvrez la page où les dates sont affichées. Cela exécutera le filtre ajouté.


• Accédez à WPML → Traduction de chaînes et traduisez les dates.


• Vous devrez traduire chaque suffixe séparément (par ex. 1st, 2nd…) car cela peut changer selon la langue.

Référence : compsupp-5773.

L’Éditeur de traduction avancé n’invente pas de slug

L’éditeur traduit le champ du slug lorsque vous le remplissez et conserve le slug d’origine lorsque vous le laissez vide. Il ne déduit jamais un slug du titre traduit de lui-même.

Ce que vous voyez

Si vous traduisez un article à l’aide de notre Éditeur de traduction avancé, le champ du slug n’est pas rempli automatiquement. Si vous décidez ensuite de laisser le champ du slug vide, il charge le slug de la langue d’origine dans l’article traduit.

Référence : wpmlsupp-8574.

Shortcodes de constructeur de pages dans une description courte de produit WooCommerce

La description courte est l’extrait de l’article, un champ de texte brut selon la définition de WordPress, donc WPML n’y analyse pas les shortcodes de constructeur de pages de la même manière qu’il le fait dans le contenu. Il se trouve que WooCommerce les affiche, c’est pourquoi ce décalage surprend les utilisateurs.

Ce que vous voyez

La description courte de produit WooCommerce est basée sur le champ de l’extrait de l’article, et il s’agit généralement d’un simple champ de texte qui ne gère pas les shortcodes. À ce titre, il n’est pas prévu que si vous collez des shortcodes de constructeur de pages dans l’extrait de l’article, ils fonctionnent, et lors de la traduction des extraits d’articles, WPML n’essaie pas de gérer ces shortcodes.

Mais WC gère ces « extraits » un peu différemment, et les shortcodes fonctionnent, mais WPML agit toujours comme s’ils ne fonctionnaient pas, et si le shortcode inclut des attributs qui nécessitent une traduction ou des liens internes qui devraient être gérés automatiquement, cela n’est pas facilement possible.

Ce qu’il faut faire

Nous avons préparé un code qui peut être ajouté sous forme d’extension pour fournir cette fonctionnalité. Copiez et collez le code ci-dessous dans un fichier que vous pourriez nommer wpmlpb-excerpts.php et enregistrez-le dans votre répertoire wp-content/plugins/, puis activez l’extension.

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

Référence : wpmlpb-686.

Un domaine différent par langue sur l’hébergement WordPress.com

WordPress.com associe un domaine à un site ; le format d’URL « un domaine différent par langue » nécessite que chaque domaine de langue atteigne le même WordPress, ce que cet hébergement ne propose pas.

Ce que vous voyez

En raison des limitations sur le fonctionnement du mappage de domaine avec WordPress.com, il n’est pas possible de choisir le paramètre des URL de langue pour utiliser un domaine différent par langue lorsque les sites y sont hébergés.

Ce qu’il faut faire

L’une ou l’autre des autres options d’URL de langue, avec des langues différentes dans les répertoires ou le nom de la langue ajouté comme paramètre, peut être utilisée au lieu d’un domaine différent par langue.

Un hébergeur différent serait nécessaire si un domaine différent par langue était une exigence.

Référence : wpmltriage-2045.

Traductions importées et éditeurs de traduction

Une importation écrit des traductions terminées ; elle ne crée pas de tâches de traduction, et les éditeurs fonctionnent à partir de tâches. Les traductions sont complètes sur l’interface publique et ne sont tout simplement pas modifiables dans l’Éditeur de traduction avancé ou classique.

Ce que vous voyez

Chaque fois que vous importez du contenu à l’aide de WP All Import et du module complémentaire WPML All Import, vous verrez parfaitement les traductions d’articles importées sur l’interface publique. Cependant, vous rencontrerez des problèmes si vous essayez de les mettre à jour à l’aide des éditeurs de traduction de WPML :

• L’Éditeur de traduction classique affiche le contenu dans la langue par défaut au lieu des traductions importées
• L’Éditeur de traduction avancé affiche des traductions vides

Cela est dû au fait que lorsque vous importez du contenu multilingue, WPML ne crée pas de tâches de traduction, qui sont nécessaires pour la segmentation des chaînes de texte.

Ce qu’il faut faire

Pour modifier ou mettre à jour vos traductions importées, veuillez passer à l’éditeur WordPress natif et utiliser la traduction manuelle.

Référence : WPMLAI-168.