Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

in my theme I want to define a series of custom post types and custom taxonomies, each one having its own customized slug; the base language of my theme is english, therefore the slugs will be in English language

for example while defining the slug of custom post type "product" args:

'rewrite' => array( 'slug' => 'product' ),

is there any way to translate the "slug" through po/mo files? can I put it as:

'rewrite' => array( 'slug' => __('product', 'mytextdomain') )

or it won't work? what's the current practice to localize slugs?

share|improve this question
    
I don't know if we are dealing with the same problem but it seems like it. To better illustrate it here is a link to an original index page for a custom post type called prensa with a slug set to prensa. Using WPML the translated's page slug is press as it can't be prensa again: /en/press/ which doesn't display anything (note that now clicking the ES link doesn't bring you back to /prensa/). BUT, if you visit /en/prensa/ it does work... –  Naoise Golden Oct 10 '11 at 16:45
    
I decided redirect the pages from /en/press to /en/prensa so the link will probably not work as mentioned any more. Too bad I couldn't use the localized slug but working-on-time is better thant url-localization-friendly –  Naoise Golden Oct 10 '11 at 17:00
    
See my answer Naoise, I think it will give you a working solution. –  chrisguitarguy Oct 10 '11 at 17:31

4 Answers 4

up vote 8 down vote accepted
+25

I wouldn't try to localize your slugs. Instead, why not give your users the option to change them by adding another field to the permalink settings page?

Hook into load-options-permalink.php and set up some things to catch the $_POST data to save your slug. Also add a settings field to the page.

<?php
add_action( 'load-options-permalink.php', 'wpse30021_load_permalinks' );
function wpse30021_load_permalinks()
{
    if( isset( $_POST['wpse30021_cpt_base'] ) )
    {
        update_option( 'wpse30021_cpt_base', sanitize_title_with_dashes( $_POST['wpse30021_cpt_base'] ) );
    }

    // Add a settings field to the permalink page
    add_settings_field( 'wpse30021_cpt_base', __( 'CPT Base' ), 'wpse30021_field_callback', 'permalink', 'optional' );
}

Then the call back function for the settings field:

<?php
function wpse30021_field_callback()
{
    $value = get_option( 'wpse30021_cpt_base' );    
    echo '<input type="text" value="' . esc_attr( $value ) . '" name="wpse30021_cpt_base" id="wpse30021_cpt_base" class="regular-text" />';
}

Then when you register your post type, grab the slug with get_option. If it's not there, use your default.

<?php
add_action( 'init', 'wpse30021_register_post_type' );
function wpse30021_register_post_type()
{
    $slug = get_option( 'wpse30021_cpt_base' );
    if( ! $slug ) $slug = 'your-default-slug';

    // register your post type, reference $slug for the rewrite
    $args['rewrite'] = array( 'slug' => $slug );

    // Obviously you probably need more $args than one....
    register_post_type( 'wpse30021_pt', $args );
}

Here's the settings field portion as a plugin https://gist.github.com/1275867

EDIT: Another Option

You could also change the slug based on what's defined in the WPLANG constant.

Just write a quick function that holds data...

<?php
function wpse30021_get_slug()
{
    // return a default slug
    if( ! defined( 'WPLANG' ) || ! WPLANG || 'en_US' == WPLANG ) return 'press';

    // array of slug data
    $slugs = array( 
        'fr_FR' => 'presse',
        'es_ES' => 'prensa'
        // etc.
    );

    return $slugs[WPLANG];
}

Then get the slug where you register your custom post type.

<?php
add_action( 'init', 'wpse30021_register_post_type' );
function wpse30021_register_post_type()
{
    $slug = wpse30021_get_slug();

    // register your post type, reference $slug for the rewrite
    $args['rewrite'] = array( 'slug' => $slug );

    // Obviously you probably need more $args than one....
    register_post_type( 'wpse30021_pt', $args );
}

The best option, IMO, would be to both give the user an option and provide solid defaults:

<?php
add_action( 'init', 'wpse30021_register_post_type' );
function wpse30021_register_post_type()
{
    $slug = get_option( 'wpse30021_cpt_base' );
    // They didn't set up an option, get the default
    if( ! $slug ) $slug = wpse30021_get_slug();

    // register your post type, reference $slug for the rewrite
    $args['rewrite'] = array( 'slug' => $slug );

    // Obviously you probably need more $args than one....
    register_post_type( 'wpse30021_pt', $args );
}
share|improve this answer
1  
+1 for the plugin on gist and the well documented code. In my case, though, it defeats the purpose, which is to not give power to the user but to make localization-aware (seo friendly) urls for custom post types –  Naoise Golden Oct 11 '11 at 17:01
1  
I'm not sure I understand why you would want to remove an option from your user. More over, running a slug through a translation filter gives them the same option: to change the slug. Just not with a pretty form field to fill out. –  chrisguitarguy Oct 12 '11 at 16:05
    
just for curiosity, why wpse30021? –  Naoise Golden Oct 17 '11 at 9:29
    
It seems as if this option is for a WPLANG-based localization. But what if you are working with a multi-language site? (for example WPML plugin). The question is more about displaying a different slug depending on the client's localization than being able to set a custom post type slug from the server's options. –  Naoise Golden Oct 17 '11 at 9:33
    
wpse = WordPress stack exchange. 30021 is the number from the URL. Good luck with your quest; I've given my answer. The additional complexity you're adding, and apparent complete change of the original question -- originally about CPT slugs, only makes the case for allowing the end user to choose their own slug. –  chrisguitarguy Oct 17 '11 at 13:27

I would recommend not making slugs translatable.

Translation is for user-facing site content. Slugs are used internally, and are only marginally "public-facing" via URL rewrites - and URLs should not be translatable, either.

So: leave your slugs alone, as you define them. Only make translatable strings that are intended for public consumption.

share|improve this answer
5  
translated slugs, both from a seo and a user experience perspective, make a lot of sense... –  Naoise Golden Oct 17 '11 at 9:20
    
I disagree that slugs impact user experience in anyway whatsoever. If a slug is used as part of a link, the link anchor text will be translated, so the user won't know the difference. And when people start tossing around "SEO", I generally think, "snake oil". I'm not an SEO expert, but I'm not buying SEO impact with respect to translated slugs. –  Chip Bennett Oct 17 '11 at 11:28
1  
I disagree based on experience. We have foreign content managers in-house who are explicit that URL slugs should be localized. It's a matter of creating a complete/ly local experience for the foreign user. For some countries, like Japan, it's literally essential to establish an authentic kind of trust and indicate you are really serious about doing business there. –  internetross Feb 14 '13 at 23:13

I am doing exactly that in a theme we are developing. It is available in 5 distinct languages, and each language has a translated set of categories. The first component of the URL in the theme is parsed to determine which language is used, in country-language format:

/uk-en
/fr-fr
/it-it

And then translated categories are parsed as further components of the URL.

The URL is parsed in the parse_request phase:

function my_parse_request( $wp ) {
    $path = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );

    $components = preg_split('|/|', $path, null, PREG_SPLIT_NO_EMPTY );

    // Determine language from $components[0]
    $language = array_shift( $components );
    ...

    // Load translations file...
    $mofile = get_stylesheet_directory()."/$language.mo";

    load_textdomain( 'mydomain', $mofile );

    ...

    // Determine category from $components[0]
    if( __( 'some-category', 'mydomain' ) == $components[0] )
      $wp->query_vars['category'] = 'some-category';

    ...
}
add_action( 'parse_request', 'my_parse_request' );

This example is devoid of requisite checks, but is meant only as an example.

There are drawbacks to this approach, of course, but it allows natural URLs in all languages. The main drawbacks I see are:

1) It doesn't make use of the permalink mechanism. This could likely be extended so that the proper permalink rules for all languages are generated and parse_request won't be necessary, but to do it for all of the languages would involve loading one MO file after another in a loop, and I don't know how well supported that is.

2) If a translator changes a slug, then the links get invalidated.

share|improve this answer

If that doest not work Why not you just simple do:

$post_slug=  __('product', 'mytextdomain');
'rewrite' => array( 'slug' => $post_slug );
share|improve this answer
    
this didn't work for me –  Naoise Golden Oct 10 '11 at 16:41
    
it is basically the same code in another style –  Naoise Golden Oct 10 '11 at 16:47
    
Have you added the proper text domain ? <?php load_theme_textdomain(my_text_domain);?> ? –  chifliiiii Oct 10 '11 at 18:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.