The main change is this release is having two modes:

• Basic – allowing only to enter multilingual contents.
• Advanced – allowing everything else too.

Before the final release, we’re also going to make the professional translation interface much simpler.

Bugs fixed since 1.3.5

A lot of energy went into finding and fixing bugs. Here’s what was fixed so far:

• Language information was deleted when doing future publishing.
• Slashes were removed from posts and pages.
• WPML admin functions didn’t work when using HTTPs.
• WPML refused to run if plugins directory was different then wp-contents (WP has some bugs there too, so care is needed when doing that).
• Admin language per user was not working.
• Language locales not set by default.
• Categories disappearing after doing quick-edit.
• Static home/blog page could not be set for new installations.
• Some MySQL query errors.
• Cleaned up the HTML in lots of places (unescaped & signs).

Any problems remaining?

So, if you are seeing one of these bugs on WPML 1.3.5, please try this version. It’s clean and can be used on live sites (running on wpml.org right now).

Make sure you report them in the forum. The devil’s in the details, so when you report problems, make it easy for us to fix by explaining how we can see it and how we can reproduce.

How do we make WPML’s admin as simple and friendly as possible, while keeping all the advanced features available?

The idea is to give WPML two modes – Basic and Advanced. Basic mode will be for people who want to run a multilingual blog with minimal setup and nothing besides the ability to translate contents. Advanced mode is for everything else.

WPML in Basic mode

This is intended for folks who want to run multilingual, but not spend any time configuring anything. Really anything. It means that some elements in custom themes may not be multilingual, but it’s not a problem in this case.

In Basic mode, WPML’s admin menu will include just the Languages page. No theme localization, string translation, etc. Just select the site’s languages and that’s it.

WPML in Advanced mode

Advanced mode will be what WPML looks like now. It includes all the functionality.

The Languages page will also appear in ‘Advanced’ mode, allowing to choose the URL structure, admin language and other fun stuff.

Unlike today, the switch between Basic and Advanced will be persistent. Meaning, once you’ve gone Advanced, it stays Advanced until you click on Basic again.

Help us tune it

To fine tune this new change, we really want to know what you’re using WPML for. This is a poll we published a while back. Click your answer here:

Thanks a lot, you’re really helping us here!

Mike wrote the following post, which makes for great reading for anyone building full sites with WordPress and WPML.

The following is a brief summary of my experience with the WPML plugin.

Primary Navigation

The primary navigation of this site is image based, so instead of using do_action(’icl_navigation_menu’), and being forced to either disable or overwrite the CSS they produce, I instead went the faster route by using the icl_link_to_element() function, like so:

<ul id="primary">
  <li class="bg link1"><?php icl_link_to_element(22); ?></li>
  <li class="bg link2"><?php icl_link_to_element(24); ?></li>
  <li class="bg link3"><?php icl_link_to_element(37); ?></li>
  <li class="bg link4"><?php icl_link_to_element(27); ?></li>
</ul>

The down side of going this route is if the page ID changes (which it shouldn’t) the link will be dead. However, the up side is that it took no time at all to implement and I didn’t have to worry about overriding the default styling that WPML applies to its “menuing” functions.

NOTE:

The WPML plugin is shipped with a style sheet that automatically styles the various navigation types that it renders. The only way to completely avoid this is to delete the styles sheets that come with WMPL. However, the do re-appear when you update the product.

In my opinion, there should be a feature built-in to WPML that allows the user to enable/disable the style sheets.

Amir: As of WPML 1.3.3, it’s possible to disable loading any of WPML’s CSS and JS files. Use one of the constants described in the coding API page.

Breadcrumb Navigation

To implement the breadcrumb trail that is shown on all pages (with the exception of the home page), I used the following function:

<?php do_action('icl_navigation_breadcrumb'); ?>

Easy to implement and did what I needed “out of the box”. However, I believe some customization should be available – namely having the ability to choose what the separator between each link should be. Granted, this is pretty minor stuff, but still, having the option would be nice.

Sidebar Navigation

Only one section of the site has sub/secondary navigation, and again I was able to use one of WPML’s built-in functions to create this:

<?php do_action('icl_navigation_sidebar'); ?>

This function has an interesting way of rendering the navigation. It first echos the parent page as a header (<h4>) and then renders the links (children) that belong to it. Again, like the other functions I’ve discussed, there is not a whole lot of customization that is available. In this case, I didn’t need any – but what if I wanted the page name (currently as an <h4> element) to be a link instead?

Amir: Good point. Just like for the top navigation, we’re going to add hooks to this function so that designers can create custom HTML for elements.

Language Switching

Finally, the language switching was where I had to do the most customization. The default method for displaying the available languages was not going to work – instead I used a nifty little function (icl_get_languages(’skip_missing=N’)) that return an array of all the available languages and a parameter for each (active) which has a value of ‘0’ or ‘1’. The active language will have a value of ‘1’, while all the other languages will have a value of ‘0’.

For this site, all I had to do was run the resulting array through the loop and when I found the active attribute having a value of ‘0’, I would return the language name, like so:

<?php
function wpml_language_switch() {
  $lang = icl_get_languages('skip_missing=N');
  $ret = '';
  if(count($lang) > 0) {
    foreach($lang as $value) {
      $ret .= ($value['active'] == 0) ? '<li><a href="' . $value['url'] . '">' .
               $value['native_name']  . '</a></li>' : '';
    }
  }
  return $ret;
}
?>

Final Notes and Remarks

In conclusion, WPML is a plugin that I intend to on any WordPress-related build that I am a part of. Even for sites that are in one language only, the navigational features that the plugin offers make it a “must have”. Sure, there are things that could be worked on and improved, but all in all it’s a great product that will only get better!

It adds a language switcher to BuddyPress bar, allowing visitors to select their languages. Then, it hooks to different elements that BuddyPress generates and makes sure they are all language sensitive.

The main blog and guest blogs can run multilingual. WPML allows different authors to select their admin language, so that different users can manage their guest blogs in their native languages.

Here is how the famous BuddyPress bar looks like with the plugin running:

BuddyPress bar with language switcher

It’s running fine on BuddyPress 1.0, and we’re working hard to complete support for BuddyPress 1.1 (should be available next week).

To get started, have a look at the (very basic) users guide.

The next step in WPML development is to add a full test suite to it. The plan is to use the Automated Testing framework used by WordPress core itself. This way, we can add new features without running the risk of breaking existing functionality.

Background and some figures

WPML started as a pretty large plugin and over time evolved into a huge project (20,000 lines of code). It provides much of the functionality you can find in other, mature, content management systems.

For instance, in Drupal, the same functionality is achieved by no less than 8 modules – i18n, country flags, translation tables, translation overview, l10n server, potx, ICanLocalize Translator and menus.

Instead of complaining about how complex it is, we better create robust tests that allow us to develop it without having to manually test dozens of scenarios on every release.

We need your help to the test suite complete

By now, you must be wondering why I’m explaining all this.

We’re making a long list of tests, which we hope will cover as much as possible. However, I’m pretty sure that we’re going to miss out on many important things that need to be tested. And here is where you get to help.

Over the next week, we’re going to set up a bug tracking system. In order to report bugs, you will need to:

1. Provide access to a place where the bug can be validated.
2. Supply information about how to duplicate it in our testing environment.

Then, we’ll be able to add this case to the bug-tracking system and track its progress. Every bug will be added to the test suite, making sure that once it’s fixed, it stays fixed and doesn’t surface up again.

Ready to help? We know that reporting bugs this way is going to be harder, but the end results would be much better. By reporting bugs in a way we can track and fix, you’ll help make WPML better.

Most people who use WordPress don’t run multilingual, so it actually makes little sense for theme designers to add support just for us. And, there are other multilingual plugins out there, so should the theme author add support for all?

We have a different idea, and I want to hear your opinion about it.

Instead of asking them to play by our tune, we’ll play by their. WPML will include a compatibility module which will allow it to use hooks by themes and plugins. This will allow us to make those themes fully multilingual without changing a single line of code (in the theme).

Here are some examples we’ve looked at:

• Thesis theme
• Thematic theme framework
• ThemeHybrid theme framework
• All in One SEO Pack plugin

We’re going to make this very easy to use and well documented. Users will be able to contribute their own theme/plugin compatibility code, so if you’re using something that we don’t know, you can make it multilingual yourself.

For example, a compatibility module for All in One SEO Pack

AIOSEOP includes hooks for reading and modifying the blog title and other texts that users enter in the plugin admin page To run multilingual, these texts need to be translated.

The compatibility module for AIOSEOP will use these hooks. It will get the texts that need translation and add them to WPML’s string translation screen. Then, when the site is displayed, it will use the same hooks to replace those strings with their translation.

Things that it will be able to do

A multilingual compatibility pack for a theme will do stuff like:

1. Translate texts that you enter in the theme administration page.
2. Turn featured categories and other IDs into multilingual.
3. Allow inserting language selectors into different places in the theme (already styled to fit that theme).
4. Fix navigation, so that everything points to the right language (like the home page link).

How does this sound to you? Would you be interested in compatibility packs for any theme or plugin?

You can grab the first beta release and try it. We’re already using it on wpml.org and it looks fine.

There are no new functions (a few minor bug fixes did make it in) and if you’re running from a very fast server, you may not notice any change. However, busy sites running on shared hosting will see an immediate improvement in site response.

Caching and prefetching for language information

WPML now includes a new caching class which is responsible for holding information that’s used more than once. Before, whenever any function needed something, it asked the database server. Now, it asks the cache which only accesses the database if it doesn’t yet have that information.

Additionally, some pages like the blog page (or home) contain multiple posts. WPML now gets the language information for all posts in one database access and saves in it the cache for when it’s needed.

The results are:

• Before language caching – 160 queries
• After caching – 17 queries

Caching for CMS navigation

We thought that there’s a problem with the language information, but the CMS navigation actually took even us by surprise.

To generate the navigational elements in wpml.org, it took no less than 250 database queries. There’s a good reason for that too. WPML’s sidebar and top navigation are complex elements. They go up and down the page hierarchy, determining what needs to be displayed.

Caching for those is now done on the HTML level. E.g., the navigation elements are produced once and then saved. Subsequent page displays will require just one single call to fetch from the cache.

It turns out that we’re not alone. If you’re using a different plugin for drop down menus, check how many database accesses it’s causing. You’re in for a surprise…

How to test database queries

If you’re wondering how to test the number of database queries WordPress does, look no further than the great Debug Queries plugin. It will show you the accesses, how long they actually took and the breakdown between PHP processing and database access time.

Let us know how it’s going. We’re looking to release WPML 1.3.3 soon and want to know if there are any problems.

How WPML’s professional translation works

1. You write contents in your language.
2. WPML sends posts and pages to ICanLocalize for translation.
3. Translators work on ICanLocalize’s translation system.
4. WPML fetches the completed translations and either publishes or holds for review.

When you use this, you can concentrate on the contents in your language and WPML takes care of the rest. For example, it will adjust links to go to other translated pages, creates pages in the correct hierarchy and handle any custom field that you’re using.

Who is doing the translation?

When you set up professional translation, you can choose between two options:

• Using translators from ICanLocalize.
• Using your own translators.

Most people prefer using translators from ICanLocalize, as they’re all excellent at their work and highly trained at using our translation system.

When you choose this option, translators from our pool would apply to work on your site. They’re all very good but each comes from a different background. So, for example, if you’re doing a tourist related site, you would probably prefer a translator who’s already worked on other similar websites.

Setting up and using professional translation

Go to WPML->Pro translation and click to enable it. Next, you need to select which languages to translate between, which translators to use and enter information for an account (just your name and email).

For now, you’re done. Over the next day or two, translators will apply for this work. You can see their resumes and chat with them.

Once you’ve selected translators, you can start sending documents to translation.

Go to Tools->Translation dashboard, select what needs to be translated (you can select everything at once) and click to send to translation. That’s it. Your translator will get it, translate and it appears back in your site.

Want to see it in action? Here’s a live demo (featuring my voice, with a slight cold):

Handing off translated sites to your clients

Web developers often need to supply sites with initial contents and then hand them off to their clients.

You can use ICanLocalize’s professional translation to build the initial translations for the client site and show off a nice multilingual site with real contents.

Then, when you hand the site over to your client, tell us and we’ll transfer the ownership of the translation to the client as well. This means that the client will be paying for the translations from now on (and of course, manage them).

And, as a sign of gratitude, we will keep you as an affiliate for that site. When we get paid for translation work, you’re credited as well. It’s just fair as you’re the one who got us the job in the first place.

If you’re building multilingual sites for clients, can you help us by participating in this poll?

The idea for this post came from a discussion in the forum about sharing custom fields and media between translations.

The goal -  a multilingual product catalog with WordPress

To set up my small bilingual shop I didn’t want to use a complex e-commerce CMS, WordPress was just the right thing for what I needed. Also I was looking forward to testing the WPML plugin on a slightly more complex project than the usual classical blog or website.

So, in my English/French online catalog, the products are each described in a dedicated post. To add a product I simply add a post in the back-end of WordPress, giving it the name of my product as title, typing the description in the content text-area, uploading the products photos to the images gallery of the post, and using the custom fields for values like price, reference and size.

Here’s how a product post in English (the default language) would look :

Now, after creating the original post for a product, how do I create the translated (French) version of it? Following WPML’s instruction, I simply click on the Language box under the post content window, click on “show” next to “Translations” and then click on “add”. It opens up a new post page where I can type in all the translated informations of my product : French title, French description, etc.

Problem – translations duplicate product information

But wait! Here is the annoying thing. I also have to type in again the custom fields values: reference, price and size. In my case those values are the same in any language so it makes no sense having to enter them twice. This is an obvious problem that would make me lose a lot of time if I had to type in the same information multiple times for each product post translation.

It’s the same issue with the product images, I don’t want to upload all the product photos a second time for the same product in it’s translated version. Logically, product photos are the same in any language, so I should be able to upload them only once.

So, let’s save the translated post just like this, without typing in a translation for the custom fields and without uploading the product images.

Ok, now let’s have a look at some code. Here’s a very basic example of a product listing page for a category (usually the archive.php file of your WP theme) :

<?php while (have_posts()) : the_post(); ?>
  <ul class = "product">
    <li class = "title"><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></li>
    <li class = "ref"><?php echo get_post_meta($post->ID, 'Reference', true); ?></li>
    <li class = "price"><?php echo get_post_meta($post->ID, 'Price', true); ?></li>
  </ul>
<?php endwhile; ?>

That’s the classical loop. It shows a list of my products and the associated custom field values – Price and Reference.

Now if I click on another language in the language selector on the front-end of my website (French in my case), it shows the translation of the articles title, but it doesn’t show the reference and the price value. That’s normal, remember we didn’t enter them in the translated post..

So, how do I get WordPress to show the custom values I entered in the original English post ?

Solution – sharing custom fields between translations

Well, WPML is a powerful plugin that provides us with a very useful function to fetch those values from the original post, even on the translated pages.

We are going to use the icl_object_id() function and replace the previous code by the following :

<?php while (have_posts()) : the_post(); ?>
<?php
  // Get the original post ID (in my case the english one)
  $o_ID = icl_object_id($post->ID, 'post', false, 'en'); ?>
  <ul class= "product">
    <li class = "title"><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></li>
    <li class = "ref"><?php echo get_post_meta($o_ID, 'Reference', true); ?></li>
    <li class = "price"><?php echo get_post_meta($o_ID, 'Price', true); ?></li>
  </ul>
<?php endwhile; ?>

Basically what we did was to retrieve the ID of the original post corresponding to any translated post, and using this ID to get the custom values. Depending on the original language of your posts, you can change the last parameter of icl_object_id (’de’ for German, ‘fr’ for French, etc.). You can get more information about the other parameters of this function here and a list of other functions in the coding API page.

That was for the custom fields, now how do I do the same with the image gallery?

Let’s take our first example and also show three thumbnails images for each post in the list:

<?php while (have_posts()) : the_post(); ?>

<?php
  // Get the original post ID (in my case the english one)
  $o_ID = icl_object_id($post->ID, 'post', false, 'en'); ?>

  <ul class= "product">
    <li class = "title"><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></li>
    <li class = "ref"><?php echo get_post_meta($o_ID, 'Reference', true); ?></li>
    <li class = "price"><?php echo get_post_meta($o_ID, 'Price', true); ?></li>

<?php

  // Get 3 thumbnails from the original post
  $args = array('post_type' => 'attachment','numberposts' => 3,'post_status' => null,'post_parent' => $o_ID);
  $attachments = get_posts($args);
  if ($attachments) {
    foreach ($attachments as $attachment) {
      echo '<li class="thumbnail">'.wp_get_attachment_image($attachment->ID).'</li>';
    }
  }
?>
</ul>

<?php endwhile; ?>

Summary

You can easily customize this little script to fit your needs, showing more (or less) images or different sizes.

That’s it. Now we can show our product list in any language, and it will always contain all the product custom fields and images, even if technically these are only stored in the original post.

This gets really interesting for bigger catalogs with more languages. Imagine you have to change the price of a product in five languages. With the normal method you would have to edit all five posts. With this easy method you always have one “master” language with its posts containing the complete information about your products and translations reusing it.

Michael Wassmer is a freelance web designer based in Barcelona, Spain. You can contact him at mike@michaelwassmer.net

Without further delay, have a look at WPML’s tables description. That page describes the languages and translation table, the country flags table and the strings translation table.

I hope that this description helps develop themes and plugins that work with WPML.

WPML’s Sticky Links – what’s that?

From time to time, folks ask us what are WPML’s Sticky Links. In case you’re wondering, you can see it by going to WPML’s menu and click on Sticky Links.

Thanks for answering this poll. Sticky Links are one of WPML’s more powerful functions and we’re trying to make them easier and more obvious to use.