Skip Navigation
Home » WPML Blog – News and Updates for the WordPress Multilingual Plugin » WPML versions » WPML 2.4.1 – Finally, duplicate slugs for different languages

WPML 2.4.1 – Finally, duplicate slugs for different languages

WPML versions
45

WPML 2.4.1 fixes a few bugs and also adds a highly anticipated new feature. Finally, your posts and pages can have the same name in different languages.

This time, the bugs list is relatively modest. We changed the logic in some places to allow large sites with many users to run with less memory. WPML loaded the entire table of users and posts in several odd places. This is no longer the case and now much less memory is needed on these specific Admin pages. This was something that we actually found on our own site, as it grows bigger and busier every day.

Other bugs were related to language redirect cookies for Safari, better styling for the language switcher in menus, translation for author descriptions and the title of our own languages widget.

And now, for the really fun stuff…

Duplicate post names (slugs) for different languages

I think that this has been the most frequently requested feature, starting with WPML 0.9.3. Now, you can have pages like:

  • /blog/
  • /es/blog/
  • /de/blog

It’s especially important when pages receive the names of products. Then, you really don’t want to have something like:

  • /sony/
  • /es/sony-2/ (ouch)

For a while now, WPML resolved first the language and only then the post. This fix hooks to the WordPress function that adds the integer suffix and changes it so that it too only checks for pages in the same language.

If you want to rename existing content in your site, simply edit the slugs. WordPress will now permit having translations with the same name and slug.

Please note that duplicate slugs are available for ‘posts’ only (pages, posts, custom post types) and not for taxonomy.

Custom Types and Fields Plugin

In case you’re interested, we haven’t completely forgotten about our plugin for managing custom types and fields. In fact, it’s ready for release. We’re just ironing out a few last issue with the new website and it’s up. I’ll write all about it in the next post.

45 Responses to “WPML 2.4.1 – Finally, duplicate slugs for different languages”

  1. I did a quick testing and it seems to work fine with new posts.

    However, I just can’t change the slug of existing posts. It keeps adding the suffix.

    • Maybe, first, change the slug to something completely different and then back to the duplicate slug (in the translated posts).

      • Mihai found a bug which prevents existing posts from being fixed. We’ll release a new beta soon, with this fix and you’ll be able to download it.

        • Hi!
          – Is renaming existing slugs possible now? (I mean, with any later *stable* version)
          – In any case, is it possible (and not trouble-making) to change the slug directly from the DB? (as a workaround to this bug affecting already existing pages/posts)
          Thanks! Alex

          • Yes. You can have duplicate slugs in different languages or in pages that have different parents in the same language.

    • This might be correct. We used hooks that are available for posts (including custom types). I’m not sure if they are available for taxonomy as well. We’ll test it and see if there’s something to use.

    • Mihai investigated this and it turns out that there’s no simple (or reasonable) solution for taxonomy with the same slug.

      The code for taxonomy is much more complex, as taxonomy pages can list other content.

      We found that if we filter this and try to affect it, too many things break, in places where we cannot predict.

      We’re going to leave this functionality for posts (posts, pages, custom posts) only and not for taxonomy.

    • It’s a different situation for taxonomies. The slug field in the wp_terms table is an unique key (post_name in post is not).

      The approach has to be different here since we’d have to share a term between 2 (or more) taxonomies that are in different languages.

      Right now the terms-taxonomies relationships are mapped under the same language.

      Perhaps we will add this in the future but the fact is that the we cannot apply the same logic as for posts here.

  3. Thanks for working to improve memory issues and slugs. Both are greatly appreciated! I look forward to trying out 2.4.1

    • Wonderful! The duplicate slug issue was the single biggest problem I’ve had with WPML thus far. It’s great to see this addressed.

  4. hi,
    your software have more problem with wp e-commerce.
    1- impossible to have this:
    http://www.mysite.com/product-pages/category/.. (english)
    http://www.mysite.com/pagina-prodotti/categoria/.. (italian)
    the problem is the “page products”

    2-not find checkout field, and you have to change every time the code is in the checkout class of wp e-commerce and in the plugin wp-e-commerce-multilingual, but after these changes do not work permalink… terrible.

    regards

    • We’re trying to improve the compatibility with WPEC. The main point that’s keeping us back is lack of time from the WPEC developers to work on these issues. Whatever we can do without changes in their code, we already completed. There are several functions that WPEC does without filtering, so it’s very difficult for us to handle.

      If you, and other users, would raise these issues also in the getshopped.org forums, I’m sure that we would get the required attention. Can you do that?

  5. these issues and these bugs I have often noted, but programmers have never given a proper solution, sometimes just pieces of it, however, created problems in other parts, as has happened for chckout form of wp e-commerce, for which no you can say wp e-commerce and are compatible wpml.
    I hope you to crop, however, solve the problems that I mentioned, if you manage to do so will be the first to say “very good” and buy the product anyway for sites where you do not use wp e-commerce is a good product.

    • You’re absolutely right. I updated the text in our compatibility page, explaining the current situation and suggesting people to speak up in the GetShopped.org forum. I hope that many people will do that and we’ll get more attention to our requests.

  6. ok amir 🙂
    I have sent several requests to GetShopped.org, as always, do not say never and do not have documentation.
    wp e-commerce it’s a good product, but the support it’s terible.

    However, these bugs will be resolved soon, I’ll be the first to buy wpml and convince my friends to take it:)

    regards

  7. Thank you for this great improvement!
    I’m also using WP e-commerce…
    It will be perfect when it will be possible to duplicate the slugs for categories & products.

  8. Just tested too whether it works to have 2 same slugs for the different languages. It seems to me that it only works on new (translations of) posts/pages/custom post types, but not for existing content…

  9. I don’t know what you change in 2.4.1 but with Catalan default language any page i want translate, is unrelated with his spanish translation for example.

    I can’t assign any page to a translation in Edit form, because nothin appear on dropdown select.

    I go back to 2.4.0, hope that solve my problem.

  11. Hi guys. The way things are right now, themes that are localized have their l10n files in a /languages folder inside the theme’s root folder. WPML on the other side is looking for l10n files in the theme’s root folder. Any chance that this be changed? Maybe give an option to choose the l10n folder (or file) for a specific theme?

    Thanks.

    • WPML scans the theme directory and locates the first folder that has .mo files. If the root directory has no .mo files, it will look in the directories below it.

  12. Strange, that isn’t working for me. I tried it a few months ago and just now… I’ll try to post a thread on the Forum to get it working then.

  13. Also, unfortunately, numbers are still added to my slugs. I can’t have same slugs for the same articles in different languages.

    WPML2.4.1, WP3.3 Multi Site

  15. I noticed a possibly related change. The is_page() function now returns false if you pass in the ID of the translated page. For example:


    $page_id_en = 18;
    $page_id_fr = icl_object_id($page_id_en, 'page');
    // On that page (in both languages):
    is_page($page_id_en); // true
    is_page($page_id_fr); // false

    Is this done on purpose because I will need to change quite some if-constructions in my template files? Thanks.

  16. I am using the Anolox theme from ThemeForest. It claims to be translation-ready. I’ve set up my site for French and English.

    Everything is working well except that at the bottom of each page, the language switcher is in the present language, not in the destination language. This seems a bit backwards to me. If you’re reading in French and you want to switch to English, it doesn’t make a lot of sense for the language switcher to be written in French (‘anglais’). Can this be changed ?

    Thanks !!

    Chris

    • WPML lets you use the exact same slug for posts, but not for taxonomy. I’m not sure if Harshad noticed what you’re posting about. Post types (pages, posts and custom post types) can have the same slug in different languages. Taxonomy cannot.

  18. Hi,

    Yes same problem here, I created the pages in different languages and now that I wanted to change the slug, I can’t!

    Hope this bug will be fixed soon, thanks.

  19. The ability to assign the same slug to the sibling terms of two different taxonomies would be something I’d pay huge money for. The problem is, WP seem hell-bent on not modifying the DB schema (perhaps for good reason). It would be nice to have this functionality though.

    • Same for us. I wouldn’t actually kill anyone for that, but we want it very much. Problem is, WordPress rewrite rules are very strict when it comes to taxonomy. With WordPress 3.4 and 3.5, each taxonomy, no matter what language, has to have a unique slug. Maybe this will change in a future release, but for now, we shouldn’t attempt to hack this requirement. As you’ve noticed, it will cause a big mess in the WordPress schema and make compatibility with themes and plugins problematic.

      • i’m sure the unique slug requirement was put in place for a good reason. I think you hit the nail on the head there though, it wouldn’t be too much of a headache for the guys at WP to introduce the functionality going forward, the problem for them is ensuring backwards compatibility. I think they are frightened at making this sort of change at such a late stage in the game.