Traducción de slugs para archivos de tipos de contenido personalizado

Cuando registra tipos de contenido personalizados manualmente, WordPress le permite establecer un slug de archivo distinto. La forma en que configure esto determina si el slug se traducirá a su idioma secundario o no.

Al registrar tipos de contenido personalizados manualmente, puede establecer un slug de archivo distinto utilizando la función has_archive.

WPML permite que has_archive se establezca como una cadena. Sin embargo, si el valor de la cadena se establece en algo distinto a rewrite['slug'], o no se establece el slug del nombre del tipo de contenido personalizado, el slug del archivo no será traducible.

Establecer un slug traducible

En este ejemplo de código, establecemos 'has_archive' => true. Suponiendo que el slug book se ha traducido como libro en español, los enlaces del archivo son los siguientes:

Inglés (idioma predeterminado): http://mydomain.tld/book/

Español (idioma secundario): http://mydomain.tld/es/libro/

	 	 
add_action( 'init', 'create_post_type' );	 	 
function create_post_type() {	 	 
   register_post_type( 'book',	 	 
      array(	 	 
         'labels' => array(	 	 
            'name' => __( 'Books', 'textdomain' ),	 	 
            'singular_name' => __( 'Book', 'textdomain' )	 	 
         ),	 	 
         'public' => true,	 	 
         'has_archive' => true,	 	 
         'publicly_queryable' => true,	 	 
         'exclude_from_search' => false,	 	 
         'show_ui' => true,	 	 
         'show_in_menu' => true,	 	 
         'query_var' => true,	 	 
         'rewrite' => array('slug' => 'book'),	 	 
         'supports' => array('title','editor', 'custom-fields','thumbnail')	 	 
      )	 	 
   );	 	 
}

Establecer el mismo slug en los idiomas predeterminado y secundario

En este ejemplo de código, establecemos una cadena específica para el parámetro 'has_archive' => 'my-books'. Ahora los enlaces del archivo son los siguientes:

Inglés (idioma predeterminado): http://mydomain.tld/my-books/
Español (idioma secundario): http://mydomain.tld/es/my-books/

	 	 
add_action( 'init', 'create_post_type' );	 	 
function create_post_type() {	 	 
   register_post_type( 'book',	 	 
      array(	 	 
         'labels' => array(	 	 
            'name' => __( 'Books', 'textdomain' ),	 	 
            'singular_name' => __( 'Book', 'textdomain' )	 	 
         ),	 	 
         'public' => true,	 	 
         'has_archive' => 'my-books', // Do not use the gettext functions for this parameter	 	 
         'publicly_queryable' => true,	 	 
         'exclude_from_search' => false,	 	 
         'show_ui' => true,	 	 
         'show_in_menu' => true,	 	 
         'query_var' => true,	 	 
         'rewrite' => array('slug' => 'book'),	 	 
         'supports' => array('title','editor', 'custom-fields','thumbnail')	 	 
      )	 	 
   );	 	 
}

Solución de problemas con slugs personalizables

Algunos temas y plugins permiten al administrador del sitio establecer slugs personalizados para sus tipos de contenido personalizados y taxonomías personalizadas.

Si sus slugs personalizados traducidos devuelven un error 404, compruebe lo siguiente:

El tipo personalizado siempre debe registrarse con el mismo slug en todas las peticiones: por idioma, frontend, backend, AJAX, heartbeat, etc. Por lo tanto, en 'rewrite' => [ 'slug' => $my_custom_slug ], el valor de $my_custom_slug no debe cambiar de una petición a otra, incluso si proviene de una opción (o de cualquier configuración personalizada).

WPML solo admite la traducción del slug personalizado (cuando se registra el tipo personalizado), pero no la estructura de enlaces permanentes personalizada.

Si el slug personalizado se almacena como una opción, no debe registrarse como una admin-texts en el archivo wpml-config.xml.

Después de actualizar el valor de un slug personalizado, el tema o plugin también debe vaciar las reglas de reescritura (llamando a flush_rewrite_rules();).