Although there’s no big new feature, this update is highly recommended for everyone. This release fixes some 36 issues. None of these issues was a showstopper, but they needed fixed none-the-less.

Fix highlights:

• URL preview display bug for some pages
• Non-English characters not converted to equivalent English chars in post slug
• Language switcher CSS positioning on the admin dashboard
• Inconsistent messages about translator actions with WPML’s Translation Editor
• Warning popup messages showing in wrong places
• Compatibility problems with WordPress 3.0.x and 3.1.x (are you still using that?)
• Pagination and search not working together for String Translation
• Gravity Forms integration issues
• IE7 Javascript issues
• Sticky Links not processed correctly for some links
• Stick Links not reverting correctly in some cases
• HTML entities not processed correctly for some fields when coming back from ICanLocalize.com translation
• Fixed the display of the admin language switcher for RTL WordPress administrators

and a bunch of PHP notices in different place…

You’re probably wondering how comes we got so obsessed with hunting down every tiny little issue.

Well, meet Bigul. Bigul is our new QA chief. He’s taking WPML and shaking it like never before. Then, he shakes some more and doesn’t stop until all the bolts and screws are fastened properly.

The changes are applied to all of WPML’s components. Please update WPML core and every addon plugin that you’re using. I hope that you enjoy this new release and the additional stability it brings.

Now that we’ve handled all these issues and we have a solid QA process, we’re getting back to adding more new features. I’ll write much more about it as we’re getting closer to WPML 2.5.0.

This release improves compatibility with the current BuddyPress (today, it’s 1.5.3.1). It fixes a number of bugs and feature gaps that opened since our last release.

To try this, download the current Beta:

bpml.1.3.0-b2.zip

Thanks for everyone who’s helping with testing and feedback!

The bug caused the permalinks preview box to display incorrect URLs in certain cases. It’s a long story, full of drama and boring SQL. The bottom line is, that if you’re seeing incorrect URLs in the permalinks preview, when editing posts, this beta should solve it for you.

It’s not a critical bug. This error is only in the preview. The actual page URLs are fine. However, if you click on that ‘view post’ button, you’ll get to a 404 page, since the preview URL is not correct. The actual pages display normally when you navigate to their correct URLs.

How to download

To download this fix, log in to your WPML account. Go to Downloads, scroll all the way to the bottom and download the recent beta version. The beta version is a ZIP that contains other ZIPs. Unzip it locally and upload the WPML components that you’re using.

When’s the final 2.4.3 release?

We have a few more really minor bugs to clean and then we’ll release WPML 2.4.3. Besides this glitch, 2.4.3 fixes a number of other issues, which are less obvious. This permalink preview thing is very noticeable and disturbs many of you, so we released this version today.

Let us know

If you’re still seeing anything wrote, please report in the forum. Sorry for all the trouble and thanks for your patience!

To translate your gallery, make sure that the String Translation module is enabled.

Translating strings in NextGen Gallery

All the gallery strings are under context ‘plugin_ngg‘. Don’t confuse this with the ‘plugin nextgen-gallery’ strings. The later ones are for translation of strings in NGG’s PHP, not in your galleries.

The string names will tell you what you’re translating. For example, gal_2_title is the title of gallery 2. pic_6_alttext is the ALT tag for picture 6. You probably get the idea…

The image and gallery texts will show according to the language of the page it’s been inserted to. You can insert the same gallery to pages in different languages and you’ll see different texts. The images remain the same.

We put together a small working example here:

http://subsite1.wpml.org/fr/french-album/

You can play with it and see how the gallery texts update when you change language.

What next?

We think that this round covers everything. The author of NGG is waiting for our OK to include these changes in NGG code.

Please help us test. When you tell us that it’s OK for you, we’ll pass the update on to NGG author and it will become part of the code for good.

Speed and performance optimization are an endless tunnel. No matter where you are, there’s always room for improvement. There are the simple and trivial optimization steps and the more advanced ones. The results you’ll get are very dependent on the amount of effort you’re willing to put in.

First, it’s important to understand the basics.

When a visitors go to your site, they need to receive a response, in the form of a page.

Page Caching

Your first line of defense is page caching. Page caching will return the response from the disk, or from memory without asking WordPress to prepare it. Obviously, using page caching is the one most important step towards a fast site.

In our sites, we use either WP Super Cache or W3TC.

• WP Super Cache – easier to configure and harder to go wrong. We use that on low-traffic sites, where we just need page caching to avoid WordPress from processing each and every request.
• W3TC – a complete package for speed optimization, requiring reasonable understanding of what you’re doing. When used correctly, W3TC can perform every optimization possible for your site. However, you need to understand what you’re doing and it’s possible to crash your site when you don’t. We use W3TC on wpml.org and wp-types.com, which are relatively high-traffic sites and speed is critical. We use every single feature in W3TC to squeeze out all the performance we can.

If you’re interested in more details, check out my older, but still relevant. post about WPML and W3TC.

CDN, Minify, Object Caching and APC

Besides the basic page caching, there are a number of techniques to further improve your site’s performance. Here are the popular ones:

CDN (Content Delivery Network): Your static files will be hosted on other servers, closer to visitors. Instead of hitting your server to get static content, this content will go directly from the CDN. There are different CDN providers, such as MaxCDN and Amazon. On our sites, we use Amazon S3 + CloudFront.

Minify: Pack static CSS and Javascript files into fewer files. This way, instead of loading dozens of tiny CSS and JS files, visitors will load fewer and larger files. If you also use a CDN, this doesn’t have an effect on your server, but can greatly enhance the browsing experience by first-time visitors.

Object Cache: Stores data units that take long to compute. You can read more about that in WordPress codex.

PHP Opcode Cache: Pre-compiles PHP code, so that it doesn’t have to be interpreted from scratch for every page load.

There are plugins that implement each of these operations. W3TC implements them all too.

Specific Optimization for Your Site

Page caching, CDN and Object Caching will give your site the initial speed boost. They prevent WordPress from executing, or from executing from scratch, for every single request. However, even with all the caching in the world, sometimes, WordPress does need to produce content. Then, if it takes 40 seconds for a page to compute, it’s not going to fly.

To optimize the performance of page-rendering by WordPress, you must first understand where most of the time is spent.

I recommend to start with a plugin called Debug Queries. Enable it and look at your site’s footer. You’ll see exactly how much time PHP processing and database processing took. You’ll also get a breakdown of the individual queries that make up each page.

Debug Queries output

I cannot stress enough how important doing this is for your site. Without checking what your site does now, there’s no way to tell where there’s waste and what needs improving.

You should look for things like:

• The same query running over and over again.
• A series of queries loading individual items instead of a single query loading the entire array
• Joins on huge tables, which take long to perform
• Queries that search by columns that have no index, or text searches

All these things will surely slow your site and can be avoided. Many times, you’ll see them happening in conjunction, with a single solution to fix a few problems together.

Often, in order to really fix these issues, someone is going to have to work hard on the site’s coding. In other cases, different usage of widgets or theme options can greatly reduce the database load and increase the site’s speed.

Using WPML Better

WPML has several features that help you manage your site, but also require database resources to run.

String Translation Features

WPML’s String Translation module is fairly optimized and should not slow your site, just as long as you know what you’re telling it to do.

It already comes with a caching engine, which will load entire contexts in a single query. When  a plugin, or your theme, loads translation using a GetText call, or directly using WPML’s icl_t function, WPML will load all the translations for that context. This means that other strings that belong to that plugin or theme are already in memory. This is similar to the way GNU GetText operates.

The String Translation module includes several features which help you locate and register strings for translation. To work, they require the database. These features are not intended for normal production usage and only affect performance for logged-in users.

They are explained in the String Translation performance FAQ.

Auto ID-Adjust

WPML creates different posts for different languages. Many themes refer to specific posts and want to load them from the database. They don’t know that you’re using WPML, so they don’t care about the same page appearing on different posts for different languages.

To allow you to use your themes, without any PHP edits, WPML include a handy feature that automatically converts IDs to those in the current language. If your theme attempts to load a page in English, but the site is now displaying in French, WPML will deliver the French page instead of the English page.

To do this, WPML needs to query the database, look for the French translation and deliver this instead. This operation requires database access.

You can control how this works by enabling and disabling the feature called Adjust IDs for multilingual functionality, under WPML->Languages.

Auto ID adjustment control

For smaller and less busy sites, it might not be worth the trouble. However, for busy and performance-critical sites, we recommend to disable this option and do the ID adjustments yourself.

Use WPML’s icl_object_id function to do this manually, thereby saving many accesses on places where the ID conversion is not really required (but WPML cannot tell that). On this site, we handle ID conversion manually. It’s only needed in a handful of places.

Separate WPML’s Impact

While there are many things that you can optimize, which are not all related with WPML, we want to know that we’ve done our job right.

Grab a copy of your database and run it locally. Try with and without WPML.

If you see a huge change when you enable WPML, we want to know about it. By huge, I mean that it might take 70 queries without WPML and 900 queries with it.

You can post about your experience here, or in our technical forum (better). If we need your database dump to reproduce this situation, we’ll email you to get it privately.

WPML became a commercial product in 2011. While last year, we focused on adding new features, our goal for this year is broader. We’re seeing major trends in the WordPress landscape, and intend for WPML to play a key role in them.

WordPress Trends in 2012

While WordPress became the dominant CMS in 2010 / 2011, we think that 2012 will see WordPress maturing as web-application. We’re already seeing a lot more focus on e-commerce, listing and review sites and other complete applications.

There are already new and exciting e-commerce plugins, joining the older and more well-known ones. It’s been great for everyone. As JigShop, WooCommerce and MarketPress came out, WP E-Commerce developers had to step up and revamp their code. No matter which e-commerce plugin you’re using today, you’re getting a much better product than you did a year ago.

Besides e-commerce, plugins that help customize WordPress have gotten extremely popular. Almost any WordPress site today uses something for custom fields and custom post types management. This means that we’re all using WordPress far beyond pages and posts.

There’s also a wide selection of great themes, that help build complex sites without any coding. Just drag the elements you want, where you want them, and you’re good to go.

Our part is to provide you with a seamless integration experience, allowing you to create complex multilingual WordPress sites, with all these great features.

Mobile Everywhere

Mobile web and touch screens are no longer somewhere over the horizon. They’re here now and they’re here to stay. If my 8 year-old knows how to operate a tablet – I can say for sure that that’s a winner.

We need to make sure that everything that runs well on a PC, also looks great on a tablet. For WPML, it means making it easy for admin and visitors to choose their language.

Never Forget the Basics

Trends are great, but we must never neglect our basics. These are the features that got WordPress and WPML to become so popular. To stay ahead, we need to always keep these basics in mind and in the code:

• Stability – it needs to work without bugs or glitches
• Security – it must be bullet-proof secure
• Compatibility – it needs to work with other plugins and themes
• Performance – it must run lightening fast and stay lean
• Ease-of-use – it must be intuitive, even without having to read Help documents

Stability, security and compatibility have been our main focus in 2011. We’re looking to boost performance even more in the next major release of WPML.

Our own sites run pretty fast because they’re already optimized. If you build a theme from scratch, you can guarantee its performance. We see most performance issues with complex themes that were not exactly designed to work with WPML. In the near future, I’ll write more and explain about how to check if your site’s performance is great and if there are things to improve. Then, we’ll be happy to receive test cases from you, showing where there are bottlenecks.

Also, we recognize the fact that as we added more and more features to WPML, its interface might have gotten a bit complex. We’ll be doing a major round of usability improvements and we’ll be happy to get feedback about it.

Our Goals for 2012

Full Compatibility with all Major E-Commerce Plugins

I know that we’ve been through this before and not always with the best results, but we feel that things are going much better now.

We’ve already got good compatibility with MarketPress and WooCommerce. JigShop is coming next and should be available in the next plugin release.

We finally managed to nail down the major issues with WP E-Commerce. With a bit of help from you guys, I hope that we can push our suggestions into WPEC code and be finally able to announce that it’s working great together.

Allow Building Complex Multilingual Sites

It took us six months, and now, we’re ready with Types and Views (still in Beta, but looking great). These two plugins are our solution for running complex WordPress sites, which are fully WPML compatible.

The upcoming Types and Views versions will allow to build things, never before seen with WordPress. We’re taking powerful features from web-development platforms, such as Ruby-on-Rails and implementing them inside Types and Views. We’ll try to give all that power, but without a fraction of the complexity. Yes, it’s a challenge.

This will allow building complex sites that have interconnected content types, inline lists of related data and other goodies. I’ll write more about that, as we approach the finish line.

For multilingual sites, the challenge is to make everything easily translatable. Since we’re using WPML, Types and Views for our own sites, we’ll make sure that this happens.

Run Faster

We want to see multilingual sites run faster, without having to spend days optimizing database queries. This means that WPML will pre-load and cache results and avoid hitting the database for content that it already loaded once. This is easier said than done. With different themes using the database very differently, we’ve got a lot of analysis and design work, before we can get down to coding.

Be Simpler

Simple can mean many things. Just having a minimalistic GUI doesn’t always mean it’s easy to quickly find what you’re looking to do. We want to make the entire user-experience around WPML better. This includes the site administration, content entry for writers and editors and translation process for translators.

We’re pretty used to how things are, so we’ve kinda developed a blind spot to usability issues. Suggestions are welcome

See You There!

We’re very happy about how 2011 ended and we want to make sure that 2012 turns out even better. A lot of the new development in WPML was due to your feedback. Keep working with us to make WordPress, WPML and your projects the best they can be.

If you have ideas or suggestions, leave comments here. For technical help, check out our technical forum.

If you live in Japan or China and want to work with us, we’d love to talk with you. This can be either full-time or part-time position.

Your responsibilities would be:

• Helping in dedicated Japanese / Chinese sections of our forum
• Representing us in local WordPress events (we pay all expenses)
• Helping WPML marketing efforts in your country and getting a 30% affiliate commission for that

This job will have a fixed pay and performance-based payment.

If you’re interested, please use our contact form and tell us a bit about yourself.

Custom Fields Shortcode popup

Custom Fields Shortcodes lets you insert shortcodes for any custom field, regardless of how it was created. With this, you can easily add custom fields to post content without any coding.

But the real power is revealed when you use it in conjunction with Views. Then, you can design entire sites, create complex layouts and display any content, without writing a single line of code.

To top this off, Custom Fields Shortcodes uses the field output API that other custom field plugins create. When this API exists (like for the Advanced Custom Fields plugin), fields output will go through it. Instead of just dumping the custom field value to the output, you’ll get the complex output that the plugin developer intended.

Custom Fields Shortcodes is free. You can get it, rate it and vote for it in the WP plugins repository:

http://wordpress.org/extend/plugins/custom-fields-shortcodes/

Enjoy!

The nice thing was that WooCommerce uses WordPress in a very clean way. This allowed us to turn it multilingual without resorting to any hacks.

We added a few filters to WooCommerce, created a new glue plugins called ‘WooCommerce Multilingual’ and added a bit of support for the new functionality in WPML.

To try all this, you’ll need to download:

• WooCommerce 1.4 or above (it’s always a good idea to use the most recent version)
• WooCommerce Multilingual
• The recent WPML version (from your WPML account)

How it works

The glue plugin doesn’t have any GUI and there’s nothing to configure. It hooks to WooCommerce and makes it multilingual.

You’ll need to add translations for the standard shop pages and add the same shortcodes to them. This will let the checkout and other standard WooCommerce pages appear.

There’s a complete WooCommerce Multilingual Users Guide which you should read when you get started.

Translating products

Go to a product page. You’ll see the languages box. Add on the + icons to add translation. WPML automatically synchronizes the product attributes, such as cost, weight and other properties that should be the same for all languages.

You can also use WPML’s Translation Dashboard to mark products for translation and send all at once.

Shipping and inventory tracking

Shop owners will see all orders going through on the products in the default language. When visitors add products to the cart, WPML will convert them to the products in the default language. It coverts back to the current language for display purposes.

This means that you’re tracking inventory only once per product, no matter in which language it was ordered.

Email notifications

WPML will set the locale to the client’s language when you send your client emails. Meaning, if a client ordered a product when viewing it in French, the client will receive the notification emails in French. For this to happen, you need to have the .mo files for WooCommerce in each language.

Feedback?

This release is the result of weeks of planning and development. We’re eager to receive your feedback and hear about how it’s working for you. Once we know that things are good and complete, this will go into the WooCommerce official code and continue being maintained there.

These were the main challenges we faced:

• Swap the navigation, footer and other theme elements from left to right
• Adjust some fixed-position elements in the home page for proper RTL display
• Swap all floating images in posts and pages from left to right and right to left
• Display blog posts in the correct direction – we display both Hebrew or English for untranslated posts

To handle all of them, we added an rtl.css file, which loads after the theme’s CSS. This file overrides attributes for RTL display and makes the required changes for Hebrew display.

The CSS

You have 2 options for showing the correct style and layout for your RTL language:

1. Load your standard CSS and ALSO load a new CSS with only the specific changes for RTL
2. Load a new RTL CSS INSTEAD OF your standard CSS

For this site we went with option 1 and we created a rtl.css file, but you should know that if you prefer option 2, there is a really cool tool from Google called CSSJanus. This tool is a nifty python script that will read your CSS and change (almost all) the necessary values to convert your theme from LTR to RTL.

But as we did our CSS changes manually, here are the usual changes that you’ll most certainly need:

• Add direction:rtl; and text-align:right; to the body tag (or your content wrapper)
• Change all float:left; to float:right; and the other way around.
• Change all margin-left to margin-right and the other way around.
• Look for objects with position:absolute; and move accordingly.
• Look for objects with exact background-position, and move accordingly.

You get the point, but CSSJanus unit test case will give you more cases that you need to check for.

The HTML

Be sure that you have the html tag correctly coded:

<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>

The PHP

If you proceed as we did using an extra CSS file, you can use WPML’s constant ICL_LANGUAGE_CODE to conditionally include that new CSS. In our case, the RTL language is Hebrew, so our conditional inserted just above the </head> tag in header.php look like this:

<?php if (ICL_LANGUAGE_CODE == "he"): ?>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_directory'); ?>/rtl.css" type="text/css" media="screen" />
<?php endif; ?>

That alone should do it, but we have another trick for you today. In our hebrew blog we have mixed languages. Some posts are in hebrew, some in english. So we needed a way to style each post in the loop give its language. Here is where the new wpml_get_language_information API function in WPML comes handy. This is how the start of our loop in our blog index looks like now:

<?php
while (have_posts()) : the_post();
    $lang_info = wpml_get_language_information(get_the_ID());
    $direction = $lang_info["text_direction"] == 1 ? "rtl" : "ltr";
?>
    <div id="post-<?php the_ID(); ?>">

So now, each post is wrapped in a DIV with the correct class, which we can style correctly.