38

We’re happy to announce WPML 2.5.1 with new SEO goodness, performance, stability and fully ready for WordPress 3.4.

You know, for some releases, we spend 6 weeks on one huge feature and for other releases we pack a ton of small things all over the place. WPML 2.5.1 is the later. Instead of one huge new module, you’ll discover many improvements almost everywhere.

We found a small glitch in version 2.5.0 and had to update again. The current download version is WPML 2.5.1.

WordPress 3.4 – Ready

WordPress 3.4 is just around the corner. Although it’s still in Beta (4), it’s looking pretty good. We ran a complete QA cycle on WP 3.4, fixed a few glitches and we’re very happy to say that WPML 2.5.1 works smoothly on WordPress 3.4.

Replacing Non-ASCII Characters in URLs

Isn’t it cool to see a URL with Japanese characters?

URL with Japanese characters

Cool, but apparently damaging. Just look at how this URL looks in ASCII form (what computers ‘see’):

URL with Japanese characters

Still think it’s cool? Not so much. I would call it ‘problematic’. Each one of the Japanese symbols it converted into a long sequence of ASCII characters. Browsers do the decoding, to display it in the human form, but they send the encoded version to the web browser, which passes it to WordPress. Then, WordPress needs to figure out which page we’re actually looking for.

And, you know, WordPress generates rewrite rules that parse and understand these URLs. So, why do we think that it’s problematic? Here’s why:

  • It’s fragile – if anything breaks, this breaks first. If some part in the URL decode chain truncates or mis-decodes part of the URL, this sort of URLs will break first. If your site has 15 pages, most chances you’ll be fine. If you have 500 pages, there’s a good chance you’ll see 404 pages here and there. Unfortunately, these problems happen when you’re least prepared, like when a new WordPress version comes out, or when you upgrade the caching plugin. Been there, done that.
  • There’s no way people can pass these URLs to one another. Indeed, there are URL shorteners, but do you really want to force people to use one, just because you’re producing huge URLs?
  • Search engines HATE these URLs. This was a bit counter intuitive for us, but it’s been tested and verified. While I’m sure that Google can technically decode these URLs and put the to good use, it seems it doesn’t attempt to do that. Maybe the busy Googlebot has better things to do. Once we replaced the key URLs on our site from having Japanese to ASCII characters, we get lots more traffic.

So, if we agree that non-ASCII URLs might not be the best thing to you, let’s see how to avoid them. When you translate manually, it’s not a problem. Edit the slug and enter whatever reasonable URL you want. Use ASCII characters and it’s going to be fine.

When you translate with WPML’s Translation Editor, you can now control the slugs.

Translated URL options

Now, you control the slug of translated pages. The first option is what we had until now. The second option means that the translator will explicitly enter the slug in the Translation Editor. The third option means that WPML will copy the slug of the original language in case the translated language uses non-ASCII URLs. To me, that’s the simplest option. It means that everything works as it did until now, but when translating to ‘problem’ language, the slug will be the same as English.

Tell Google About Translations and Get Some Love

Besides us, who else is obsessive about details? Right – Google.

Google wants to know everything about your site and recently they also added a way for you to tell what’s translation of what. It’s done using the hreflang attribute in links.

To make Google happy, WPML 2.5.1 adds support for these tags. Now, when you use WPML’s language switcher, you’ll also be telling Google where they can find the translations for this page and in what language.

Language information in WPML's Language Switcher

According to Google, this will make your site’s structure clearer to Google. When it’s clearer, it also ranks better.

Bug Fixes and Improvements

We’ve had the pleasure of fixing a good number of bugs. Fortunately, none of these is a critical issue, but put together, it’s a hefty collection of fixes and improvements.

Menu Sync

The menu synchronization module in WPML received a major overhaul in this release. It’s fairly complex logic and now is a lot more robust. You’ll find that menu sync works much better under wider conditions. This include custom post types in the menu, categories, custom links and other goodies that WordPress supports.

Way Way Faster String Translation API

We got this while checking compatibility status with PageLines theme. When visiting the PageLines Meta admin page, load time jumped from a couple of seconds to almost a minute.

After a short investigation, which tool almost a week, we completely revised the caching mechanism for WPML’s String Translation API. Now, without any change in the API, or any functional change, WPML can translate other plugins and themes a lot faster. If you’re translating just a few strings, you might not feel any impact. But if you’re using a complex theme which has a good number of texts in its admin screen, the impact will be huge.

More Filters for E-Commerce Plugins

This release includes a number of new filters that our glue plugins for WooCommerce, JigoShop and MarketPress use. If you’re using any of these, things that might have been a little cranky before will suddenly work better now. Yes, there’s some way to go, but this release makes it a whole lot more stable. Of course, you should also update the e-commerce glue plugin.

A Bunch of Little Sticky-Links Issues

WPML’s Sticky Links module got a major push in this release. We’ve cleaned a considerable number of issues and made it more much more robust. If you’re using it for custom post types and have arguments with all sorts of attributes, you’ll discover that Sticky Links generation and revert work like a precision tool now.

Ironed Out all Types-Related Issues

Types is our own plugin for managing custom post types and custom fields. Most of you are probably already aware of it by now. One of the greatest things in Types is that it’s 100% compatible with WPML. This release makes true on that promise. Since Types 1.0 came out, a couple of weeks ago, there were some cases where WPML didn’t correctly synchronize the new repeating custom fields. Well, it’s all working smoothly now.

BTW: While Types and WPML had some small compatibility issues, it’s a lot better than what you can expect with any other custom field plugin. We’re polishing things up, but with other CF plugins, people are still struggling with the basics. If you need custom post types and custom fields for your sites, you should really try Types. It’s built for you.

IE9 is not That Bad and WPMLs Works Fine With it (now)

I have to admit. We had a complete blackout with anything related to Internet Explorer. We did all our development on Firefox, Chrome and Safari and never even tried running on IE9. Well, Bigul, our QA chief did. While things generally worked, there were a big number of display glitches to handle. Things appearing in weird locations, Javascript running wild and all sorts of things that should be there.

We’ve learned our lesson and now our developers are constantly cycling between different browser types, including Internet Explorer.

Getting WPML 2.5.1

There are other bugs, fixes and improvements in this release, but we’re already at over 1200 words. So, without spending more time reading about WPML 2.5.1, just take it for a spin and let us know.

It’s a major upgrade. Please backup your database. We’re not expecting any problems, but we always recommend it and always back-up our own sites before upgrade.

Then, you should see this new release in the Plugins admin page. You can always download it manually from your WPML.org account, under Downloads.

Enjoy, and let us know what you think by leaving your comments here.

 

38 Responses to “WPML 2.5.1 – Too Much for Post Title”

  1. Thanks ! I was looking forward to such an update !

    I have an issue though. I updated the main plugin “WPML Multilingual CMS” but it seems I can’t update the other ones. It’s clearly stated in the WPML support page that there are updates available. However, when I click “Update” or if I check the Dashboard -> Updates, there is nothing.

    • WordPress has some catching mechanism that might be causing this delay. It should be there within 24 hours. If not, try to download manually from your WPML account. That always works.

      You should update all WPML components together, so if you already updated WPML core and you’re not seeing the update for the other parts, I recommend to login to your WPML account and download them manually.

      • Thanks Amir for your help 🙂 Indeed, after a while the updates re-appeared. I did notice a bug though: I added a translation for one of my post (by clicking on the plus button for the appropriate language), and the “link” was not done with the original post. Then later I tried to hook it to the original post using the combobox but the original post doesn’t appear in the list! I’m not sure why. I then recreated all the posts for that article, but still there is a bug somewhere.

        • Want to send us your database? Sounds like something is missing language attributes.

          If this is OK, please start a thread in our forum, explain the problem and mention that you can send the DB for debug. One of the support folks will email you so that they can get it privately.

  2. How do I install these new updates?

    I cannot do it from the WordPress plugin page, it state that the files already exist,etc.

    • This sometimes happens and is not related with WPML. It’s related with PHP locking some files. Download the ZIP files from your WPML account and upload to WordPress.

  3. I tried this new version, they are a big bug with woocommerce plugin, when you select a category for a product in other language as spanish langage and you save, it doesn’t save the category selected.

  4. Is there any plan to implement hreflang attributes in the based on which pages have been translated? Having them in the language switcher is fine (if you use it), but Google actually recommends using hreflang links in the section.

    These would be more universally useful I think.

    Well done on release.

    • We might be reading different recommendations from Google. As far as we understood, the idea is to tell Google that you’re linking to translations. Can you paste a link here that explains how they suggest to add it to the header?

      • Check here Amir:

        http://support.google.com/webmasters/bin/answer.py?hl=en&answer=189077

        HTML link element. In the HTML section of http://www.example.com/, add a link element pointing to the Spanish version of that webpage at http://es.example.com/, like this:
        <link rel=”alternate” hreflang=”es” href=”http://es.example.com/” />

        So if you have an EN page with available translations in DE and ES you would add 2 link nodes into the HEAD, one for DE and the other ES.

        You can also now add these into your sitemaps. See here http://support.google.com/webmasters/bin/answer.py?hl=en&answer=2620865

        I know you worked with Joost to bring multi-locale sitemaps into his SEO plugin, so not sure if this is a feature that could be baked into sitemaps also?

        • Thanks. I’m adding this to our todo list. In all honesty, I feel that this is going over and beyond and will not matter anything to Google. They already see these links in the language switcher and their crawlers are pretty intelligent to get the point.

          Still, it’s pretty small peanuts and we can include it in the header – just to be on the safe side.

          • One thing you can be sure of – they wouldn’t add this support if it wasn’t needed. They have quite a lot of problems determining relationships, and this adds a sibling relationship that they would not always be able to determine otherwise.

            I’ve heard some very good things about this, so it will surely be a good thing to add.

            It’s also trivial I’d say – we were going to add this ourselves but of course we’d rather you support this on your side 😉

    • This is a pretty old thread, from over a year ago. A lot has changed – both in the theme and WPML, and you shouldn’t rely on that.

      You should be able to translate everything in your site. However, some themes do things very ‘specially’ and it causes extra work. I recommend that you ask your theme author to work with us. We’re happy to work on compatibility issues with any theme author.

      Point them to this page, and we’ll take it from there:
      http://wpml.org/documentation/theme-compatibility/go-global-program/

    • Hi Amir!

      Thanks again for you prompt response earlier!

      Sadly, we’ve still been having a lot of trouble with this. After contacting the theme author, and then a WPML consultant (Senlin) as well, we’ve still been having problems. First- unrelated to things I mentioned previously, the plugin causes our test site to slow down like no other- it takes something like 6 or 8 seconds to load, now. Second, same problems as before- the slider on the Folioway theme. Senlin tried to make the plugin compatible with the theme slider and the Royalslider plugin, but unfortunately, neither worked.

      Any advice, suggestions?

      Thanks so much,

      Cyndi

      • There are some debug features that may be activated in your site, causing PHP and DB load. Have you seen this FAQ?
        http://wpml.org/faq/why-string-translation-appears-to-slow-down-sites/

        There might be other things going on, but we certainly need more information to tell. You should use a plugin like Debug Queries. Run it with and without WPML and see what’s happening differently.
        http://wordpress.org/extend/plugins/debug-queries/

        Please report it in our forum and indicate in the forum post that “It’s for David”. Once we see which queries are added when WPML is running, we’ll have a much better idea what’s going on.

        For the slider plugin, have you tried connecting the slider plugin with us? I’m sure that he’s the most qualified for editing his own code. We can help, but need his cooperation.

        • Hi Amir!

          Thanks again for all your help- sorry to keep bashing everyone’s heads against this. Quick question: is this the forum? If not, where is it?

          Also, still trying to get the theme developer to apply to the go global program, but until then, here’s some more info from the debug runs (which, if this is not the forum, I’ll repost there, for David):

          WPML ON, W3TC ON
          WordPress Plugin Profile Report
          ===========================================
          Report date: June 26, 2012
          Theme name: Folioway Imaginity Child
          Pages browsed: 21
          Avg. load time: 1.1682 sec
          Number of plugins: 10
          Plugin impact: 70.78% of load time
          Avg. plugin time: 0.8269 sec
          Avg. core time: 0.1562 sec
          Avg. theme time: 0.1992 sec
          Avg. mem usage: 23.83 MB
          Avg. ticks: 5,796
          Avg. db queries : 67.86
          Margin of error : -0.0141 sec

          Plugin list:
          ===========================================
          P3 (Plugin Performance Profiler) – 0.0099 sec – 1.20%
          Post Types Column Editor – 0.0054 sec – 0.66%
          Contact Form 7 – 0.0617 sec – 7.46%
          RoyalSlider – 0.0031 sec – 0.38%
          Sitepress Multilingual Cms – 0.6580 sec – 79.58%
          W3 Total Cache – 0.0366 sec – 4.43%
          Wordpress Seo – 0.0318 sec – 3.85%
          Wpml Media – 0.0066 sec – 0.80%
          Wpml Sticky Links – 0.0136 sec – 1.64%
          Empty – 0.0001 sec – 0.01%

          WPML ON, W3TC Off
          WordPress Plugin Profile Report
          ===========================================
          Report date: June 26, 2012
          Theme name: Folioway Imaginity Child
          Pages browsed: 8
          Avg. load time: 0.5343 sec
          Number of plugins: 9
          Plugin impact: 62.63% of load time
          Avg. plugin time: 0.3346 sec
          Avg. core time: 0.0353 sec
          Avg. theme time: 0.1486 sec
          Avg. mem usage: 21.31 MB
          Avg. ticks: 6,466
          Avg. db queries : 126.50
          Margin of error : 0.0158 sec

          Plugin list:
          ===========================================
          P3 (Plugin Performance Profiler) – 0.0057 sec – 1.71%
          Post Types Column Editor – 0.0012 sec – 0.37%
          Contact Form 7 – 0.0484 sec – 14.47%
          RoyalSlider – 0.0024 sec – 0.73%
          Sitepress Multilingual Cms – 0.2292 sec – 68.49%
          Wordpress Seo – 0.0265 sec – 7.92%
          Wpml Media – 0.0063 sec – 1.87%
          Wpml Sticky Links – 0.0147 sec – 4.40%
          Empty – 0.0001 sec – 0.03%

          WPML OFF, W3TC OFF
          WordPress Plugin Profile Report
          ===========================================
          Report date: June 26, 2012
          Theme name: Folioway Imaginity Child
          Pages browsed: 31
          Avg. load time: 0.4036 sec
          Number of plugins: 6
          Plugin impact: 29.55% of load time
          Avg. plugin time: 0.1193 sec
          Avg. core time: 0.1095 sec
          Avg. theme time: 0.1674 sec
          Avg. mem usage: 16.35 MB
          Avg. ticks: 1,196
          Avg. db queries : 46.00
          Margin of error : 0.0075 sec

          Plugin list:
          ===========================================
          P3 (Plugin Performance Profiler) – 0.0087 sec – 7.26%
          Post Types Column Editor – 0.0032 sec – 2.71%
          Contact Form 7 – 0.0634 sec – 53.18%
          RoyalSlider – 0.0039 sec – 3.24%
          Wordpress Seo – 0.0400 sec – 33.53%
          Empty – 0.0001 sec – 0.08%

          So, the W3 cache fixed some problems, but WPML is still causing the site to slow down a lot (14 vs. 7 seconds to load or something like it). Anything else you can think of? I can also attach the code that Senlin tried to implement to make the theme compatible.

          Thanks!
          Cyndi

          • I’m not sure that our support folks can help with something like this. It really calls for very specific debug and tweaking on our site.

            If something was broken or resulting in an error, they will check the source, but what you’re looking for is performance optimization work.

            The theme must be loading items from the database and WPML is checking if they are loading in the right language. This is pretty normal, but performance varies considerably, depending on what the theme is loading and how WPML is configured. Without being able to make tweaks in the theme, there’s not much you can do. Anything that you switch off in WPML will probably result in broken functionality in the site.

            Also, W3TC has quite a lot of possible configuration. For example, we’ve been using W3TC for a long time with basic configuration. Once we spent some time (and money) getting it tuned up, we saw a performance boost of around x10. There’s a lot to improve with advanced caching mode, which also requires matching configuration in Apache and the DB server.

            But, like you noticed, without the cooperation of the theme author, all this work is pretty much impossible. The theme drives the functionality of the site and we’ll have to work with the theme author to get things to work efficiently together.

  5. On the upgrade screen, it states that my current WP installation (3.3.2) is not tested with this release. This post says it’s 3.4 ready… So does it work with my installation? If yes, you should probably change the compability to 3.4 in the plugin directory, since I’m probably not the only one waiting ’till I’m sure everything works fine. Kudos for any updates though. 🙂

    • Yeah. Ignore that. We forgot to update that string in the PHP, so WordPress admin reports that warning. I’ll update it, but that’s the only change needed. You can go ahead and update. Thanks for letting us know.

  6. I have a problem with permalinks. I using WP 3.3.2 and newest WPML Multilingual CMS + WPML String Translation. Usually I can remove the permalink field and press enter, than the new slug is generated by wordpress from the title of the post/page. With activated WPML, the slug is rendered from the post/page id instead of title. And all pages get a new permalink, permalink of the static homepage.

    • I’m not 100% sure what you mean, but I’ve asked Mihai, WPML’s lead developer, to contact you and get the full details. If you can show it to him on your site, it would certainly help.

        • Can you please download the current Beta version and check? This problem should be fixed there.

          Login to your WPML account, go to downloads and scroll all the way to the bottom. There’s a ‘beta package’ ZIP. Get it, unzip and get WPML core 2.5.2-b1 from that.

    • We have a report for something like that on our forum. Thank you for demonstrating in a clip. Dominykas is working on it and I hope to have a solid fix very soon.

      • I’ve added your contact information (from this comment) to our issue tracking system. Dominykas will contact you when he needs more info or if he finds the problem and has a test version for you. Should be pretty soon.

  7. Hi, since the update 2.5.1 I have an issue with translation of the WPEC products.

    When I create a translation for a product and click the link to copy the original content, it results in an error and a broken translation.

    Could you check this issue, please.

  8. Thanks so much for working out the caching issues that were so apparent with Pagelines. I’m finally getting ready to update our site 🙂

  9. Hi,

    I saw a few comments about Pagelines here. I use PlatformPro as a theme and before buying WPML I would like to be sure this is fully compatible. I could not see this theme in your ‘Theme compatibility’ page…
    Could you please let me know?
    Thanks!