Comportamientos esperados de WPML que pueden parecer problemas

Algunas cosas funcionan de manera diferente en un sitio multilingüe por diseño: una función de WordPress basada en un término del idioma predeterminado, un sufijo de fecha que WordPress no puede localizar o un slug que el Editor de traducción avanzado no inventa. Las consultas de soporte los plantean como errores, pero no lo son. Esta página explica qué ocurre, por qué y qué hacer en su lugar.

has_category() y otras etiquetas condicionales en entradas traducidas

WPML no filtra a propósito la función has_category() del núcleo de WordPress. En una traducción, la categoría es el término traducido, que tiene su propio slug, por lo que has_category('news') es falso en la entrada en francés, aunque esta se encuentre en la categoría «news» francesa. Lo mismo se aplica a has_term(), in_category() y a cualquier código que compare un slug o ID de término del idioma predeterminado. Llame al condicional con el slug traducido o resuelva primero el ID del término mediante el filtro wpml_object_id.

Lo que ve

La función nativa de WordPress has_category no funciona para las entradas traducidas.

Un ejemplo de esto es el siguiente:

1. Tenemos una categoría con el slug en inglés “test” y su traducción al francés “test-fr”.
2. Esta categoría está asignada a entradas.
3. Cuando invoca has_category("test") dentro de un bucle en el archivo single.php de su tema, devuelve true para el idioma predeterminado, pero false para la traducción.

Qué hacer

Defina un nuevo filtro en el archivo functions.php de su 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);

Reemplace la función has_category con este nuevo filtro:

apply_filters( 'wp_has_category', 'test' )

Este filtro toma la categoría traducida basándose en el nombre de la original y comprueba si la categoría traducida está asignada a una entrada.

Referencia: wpmlcore-3024.

Los sufijos de fecha (1st, 2nd, 3rd) no son traducibles

Esta es una limitación del núcleo de WordPress, no de WPML: el sufijo proviene del formato de fecha de PHP y nunca pasa por una función de traducción.

Lo que ve

Algunos temas o plugins utilizan las funciones de WordPress wp_date() o date_i18n() para mostrar fechas. Estas fechas pueden utilizar un sufijo como 1st o 26th, dependiendo de los parámetros seleccionados.

Actualmente, no es posible traducir los sufijos de fecha debido a una limitación conocida desde hace tiempo en el núcleo de WordPress.

Qué hacer

Como solución alternativa, puede utilizar el filtro wp_date para obtener la fecha y, a continuación, modificar el sufijo antes de que se muestre en la página. Haga una copia de seguridad completa de su sitio antes de continuar y siga estos pasos:

• Añada un pequeño filtro wp_date al archivo functions.php de su tema que registre cada sufijo como una cadena (icl_register_string) y devuelva su traducción (icl_t) en lugar del sufijo en inglés:


• Abra la página donde se muestran las fechas. Esto ejecutará el filtro añadido.


• Vaya a WPML → Traducción de cadenas y traduzca las fechas.


• Deberá traducir cada sufijo por separado (por ejemplo, 1st, 2nd…) porque puede cambiar dependiendo del idioma.

Referencia: compsupp-5773.

El Editor de traducción avanzado no inventa un slug

El editor traduce el campo del slug cuando usted lo rellena y conserva el slug original cuando lo deja en blanco. Nunca deriva un slug del título traducido por sí solo.

Lo que ve

Si traduce una entrada utilizando nuestro Editor de traducción avanzado, el campo del slug no se rellena automáticamente. Si decide dejar el campo del slug en blanco, se carga el slug del idioma original en la entrada traducida.

Referencia: wpmlsupp-8574.

Shortcodes de maquetadores visuales en la descripción corta de un producto de WooCommerce

La descripción corta es el extracto de la entrada, un campo de texto sin formato por definición de WordPress, por lo que WPML no procesa los shortcodes de los maquetadores visuales en él de la misma manera que lo hace en el contenido. WooCommerce sí los muestra, y es por eso que esta discrepancia sorprende a los usuarios.

Lo que ve

La descripción corta del producto de WooCommerce se basa en el campo del extracto de la entrada, que normalmente es un campo de texto simple que no admite shortcodes. Por lo tanto, no se espera que si pega shortcodes de maquetadores visuales en el extracto de la entrada estos funcionen, y al traducir los extractos de las entradas, WPML no intenta procesar dichos shortcodes.

Sin embargo, WooCommerce procesa estos «extractos» de forma un poco diferente y los shortcodes sí funcionan, pero WPML sigue actuando como si no lo hicieran, y si el shortcode incluye atributos que necesitan traducción o enlaces internos que deberían gestionarse automáticamente, esto no es fácilmente posible.

Qué hacer

Hemos preparado un código que se puede añadir como plugin para proporcionar esta funcionalidad. Copie y pegue el siguiente código en un archivo que puede nombrar wpmlpb-excerpts.php y guárdelo en su directorio wp-content/plugins/; a continuación, active el 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,
						]
					);
				}
			}
		}
	}
}

Referencia: wpmlpb-686.

Un dominio diferente por idioma en el alojamiento de WordPress.com

WordPress.com asigna un dominio a un sitio; el formato de URL de «un dominio diferente por idioma» necesita que cada dominio de idioma llegue al mismo WordPress, algo que ese alojamiento no ofrece.

Lo que ve

Debido a las limitaciones en el funcionamiento de la asignación de dominios con WordPress.com, no es posible elegir la configuración de URL de idiomas para usar un dominio diferente por idioma cuando los sitios están alojados con ellos.

Qué hacer

Cualquiera de las otras opciones de URL de idiomas, con diferentes idiomas en directorios o el nombre del idioma añadido como parámetro, se puede utilizar en lugar de un dominio diferente por idioma.

Se necesitaría un alojamiento diferente si un dominio diferente por idioma fuera un requisito.

Referencia: wpmltriage-2045.

Traducciones importadas y los editores de traducción

Una importación escribe traducciones finalizadas; no crea trabajos de traducción, y los editores funcionan a partir de los trabajos. Las traducciones están completas en el front-end y simplemente no se pueden editar en el Editor de traducción avanzado o clásico.

Lo que ve

Siempre que importe contenido utilizando WP All Import y el complemento WPML All Import, verá las traducciones de las entradas importadas perfectamente en el front-end. Sin embargo, se encontrará con problemas si intenta actualizarlas utilizando los editores de traducción de WPML:

• El Editor de traducción clásico muestra el contenido en el idioma predeterminado en lugar de las traducciones importadas
• El Editor de traducción avanzado muestra las traducciones en blanco

Esto se debe a que, al importar contenido multilingüe, WPML no crea trabajos de traducción, los cuales son necesarios para la segmentación de cadenas.

Qué hacer

Para editar o actualizar sus traducciones importadas, cambie al editor nativo de WordPress y utilice la traducción manual.

Referencia: WPMLAI-168.