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.
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?
Cool, but apparently damaging. Just look at how this URL looks in ASCII form (what computers ‘see’):
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.
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.
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.