Comportamenti previsti di WPML che possono sembrare problemi

Alcune cose funzionano diversamente in un sito multilingue per impostazione predefinita: una funzione di WordPress basata su un termine della lingua predefinita, un suffisso della data che WordPress non può localizzare, uno slug che l’Editor di traduzione avanzato non inventa. Le richieste di supporto li segnalano come bug, ma non lo sono. Questa pagina spiega cosa succede, perché e cosa fare invece.

has_category() e altri tag condizionali sugli articoli tradotti

Il has_category() del core di WordPress non viene filtrato da WPML, di proposito. In una traduzione la categoria è il termine tradotto, che ha il proprio slug, quindi has_category('news') è falso sull’articolo francese anche se l’articolo francese si trova nella categoria francese “news”. Lo stesso vale per has_term(), in_category() e qualsiasi codice che confronti uno slug o un ID del termine della lingua predefinita. Richiama il condizionale con lo slug tradotto, oppure risolvi prima l’ID del termine tramite il filtro wpml_object_id.

Cosa vedi

La funzione nativa di WordPress has_category non funziona per gli articoli tradotti.

Un esempio di questo è il seguente:

1. Abbiamo una categoria con lo slug inglese “test” e la sua traduzione francese “test-fr”.
2. Questa categoria è assegnata agli articoli.
3. Quando richiami has_category("test") all’interno di un loop nel file single.php del tuo tema, restituisce true per la lingua predefinita ma false per la traduzione.

Cosa fare

Definisci un nuovo filtro nel file functions.php del tuo tema:

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

Sostituisci la funzione has_category con questo nuovo filtro:

apply_filters( 'wp_has_category', 'test' )

Questo filtro prende la categoria tradotta in base al nome di quella originale e controlla se la categoria tradotta è assegnata a un articolo.

Riferimento: wpmlcore-3024.

I suffissi delle date (1st, 2nd, 3rd) non sono traducibili

Questa è una limitazione del core di WordPress, non di WPML: il suffisso proviene dalla formattazione della data di PHP e non passa mai attraverso una funzione di traduzione.

Cosa vedi

Alcuni temi o plugin usano le funzioni di WordPress wp_date() o date_i18n() per visualizzare le date. Queste date potrebbero usare un suffisso come 1st o 26th, a seconda dei parametri selezionati.

Attualmente, non è possibile tradurre i suffissi delle date a causa di una limitazione nota da tempo nel core di WordPress.

Cosa fare

Come soluzione alternativa, puoi usare il filtro wp_date per ottenere la data, quindi modificare il suffisso prima che venga renderizzato sulla pagina. Fai un backup completo del tuo sito prima di procedere e segui i passaggi seguenti:

• Aggiungi un piccolo filtro wp_date al file functions.php del tuo tema che registra ogni suffisso come stringa (icl_register_string) e restituisce la sua traduzione (icl_t) al posto del suffisso inglese:


• Apri la pagina in cui vengono visualizzate le date. Questo eseguirà il filtro aggiunto.


• Vai su WPML → Traduzione stringhe e traduci le date.


• Dovrai tradurre ogni suffisso separatamente (ad es. 1st, 2nd…) perché potrebbe cambiare a seconda della lingua.

Riferimento: compsupp-5773.

L’Editor di traduzione avanzato non inventa uno slug

L’editor traduce il campo dello slug quando lo compili e mantiene lo slug originale quando lo lasci vuoto. Non deriva mai uno slug dal titolo tradotto da solo.

Cosa vedi

Se traduci un articolo usando il nostro Editor di traduzione avanzato, il campo dello slug non viene compilato automaticamente. Se poi decidi di lasciare vuoto il campo dello slug, carica lo slug della lingua originale nell’articolo tradotto.

Riferimento: wpmlsupp-8574.

Shortcode dei page builder in una breve descrizione del prodotto WooCommerce

La breve descrizione è il riassunto dell’articolo, un campo di testo normale per definizione di WordPress, quindi WPML non analizza gli shortcode dei page builder al suo interno come fa nel contenuto. WooCommerce si trova a renderizzarli, ed è per questo che la discrepanza sorprende le persone.

Cosa vedi

La breve descrizione del prodotto WooCommerce si basa sul campo del riassunto dell’articolo, che di solito è un semplice campo di testo che non gestisce gli shortcode. Pertanto, non ci si aspetta che se incolli gli shortcode dei page builder nel riassunto dell’articolo funzionino, e quando traduce i riassunti degli articoli WPML non tenta di gestire tali shortcode.

Ma WC gestisce questi “riassunti” in modo un po’ diverso, e gli shortcode funzionano, ma WPML continua ad agire come se non funzionassero, e se lo shortcode include attributi che necessitano di traduzione o link interni che dovrebbero essere gestiti automaticamente, ciò non è facilmente possibile.

Cosa fare

Abbiamo preparato un codice che può essere aggiunto come plugin per fornire questa funzionalità. Copia e incolla il codice sottostante in un file che potresti chiamare wpmlpb-excerpts.php e salvalo nella tua directory wp-content/plugins/, quindi attiva il plugin.

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

Riferimento: wpmlpb-686.

Domini diversi per lingua sull’hosting di WordPress.com

WordPress.com mappa un dominio a un sito; il formato URL “domini diversi per lingua” richiede che ogni dominio della lingua raggiunga lo stesso WordPress, cosa che quell’hosting non offre.

Cosa vedi

A causa delle limitazioni su come funziona la mappatura dei domini con WordPress.com, non è possibile scegliere l’impostazione degli URL delle lingue per usare domini diversi per lingua quando i siti sono ospitati con loro.

Cosa fare

Qualsiasi delle altre opzioni per l’URL della lingua, con le lingue nelle directory o aggiunte come parametro URL, può essere usata invece dei domini diversi per lingua.

Sarebbe necessario un host diverso se i domini diversi per lingua fossero un requisito.

Riferimento: wpmltriage-2045.

Traduzioni importate e gli editor di traduzione

Un’importazione scrive traduzioni finite; non crea lavori di traduzione, e gli editor si basano sui lavori. Le traduzioni sono complete sul front-end e semplicemente non modificabili nell’Editor di traduzione avanzato o classico.

Cosa vedi

Ogni volta che importi contenuti usando WP All Import e il componente aggiuntivo WPML All Import, vedrai le traduzioni degli articoli importati perfettamente sul front-end. Tuttavia, riscontrerai problemi se provi ad aggiornarle usando gli editor di traduzione di WPML:

• L’Editor di traduzione classico visualizza i contenuti nella lingua predefinita invece delle traduzioni importate
• L’Editor di traduzione avanzato visualizza traduzioni vuote

Questo perché quando importi contenuti multilingue, WPML non crea lavori di traduzione, che sono necessari per la segmentazione delle stringhe.

Cosa fare

Per modificare o aggiornare le tue traduzioni importate, passa all’editor nativo di WordPress e usa la traduzione manuale.

Riferimento: WPMLAI-168.