Tradução de slugs para arquivos de tipos de post personalizados

Quando você registra tipos de post personalizados manualmente, o WordPress permite que você defina um slug de arquivo distinto. Como você configura isso determina se o slug será traduzido para o seu idioma secundário ou não.

Ao registrar tipos de post personalizados manualmente, você pode definir um slug de arquivo distinto usando a função has_archive.

O WPML permite que has_archive seja definido como uma string. No entanto, se o valor da string for definido como algo diferente de rewrite['slug'], ou se o slug do nome do tipo de post personalizado não for definido, o slug do arquivo não será traduzível.

Como definir um slug traduzível

Neste exemplo de código, definimos 'has_archive' => true. Supondo que o slug book tenha sido traduzido para libro em espanhol, os links de arquivo são os seguintes:

• Inglês (idioma padrão): http://mydomain.tld/book/


• Espanhol (idioma secundário): 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')	 	 
      )	 	 
   );	 	 
}	 	 

Como definir o mesmo slug nos idiomas padrão e secundário

Neste exemplo de código, definimos uma string específica para o parâmetro 'has_archive' => 'my-books'. Agora, os links de arquivo são os seguintes:

• Inglês (idioma padrão): http://mydomain.tld/my-books/
• Espanhol (idioma secundário): 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')	 	 
      )	 	 
   );	 	 
}	 	 

Solução de problemas de slugs personalizáveis

Alguns temas e plugins permitem que o administrador do site defina slugs personalizados para os seus tipos de post personalizados e taxonomias personalizadas.

Se os seus slugs personalizados traduzidos estiverem retornando um erro 404, verifique o seguinte:

• O tipo personalizado deve ser sempre registrado com o mesmo slug em todas as requisições: por idioma, frontend, backend, AJAX, heartbeat, etc. Portanto, em 'rewrite' => [ 'slug' => $my_custom_slug ], o valor de $my_custom_slug não deve mudar de uma requisição para outra, mesmo se vier de uma opção (ou qualquer configuração personalizada).


• O WPML suporta apenas a tradução de slug personalizado (quando o tipo personalizado é registrado), mas não de estrutura de links permanentes personalizada.


• Se o slug personalizado for armazenado como uma opção, ele não deve ser registrado como um admin-texts no arquivo wpml-config.xml.


• Após atualizar o valor de um slug personalizado, o tema/plugin também deve limpar as regras de reescrita (chamando flush_rewrite_rules();).