This might be the longest post you’re reading this week, but it’s worth it. For the first time, after almost 6 months of development, we’re finally ready with a public beta of WPML 2.0.

WPML 2.0 has two major new features. These are more than just features, but new ways for doing things. We have a lot to cover today, so let’s get started.

This is a BETA version. Don’t think about installing it on live sites and don’t upgrade anything from WPML 1.8.3 to this version. There’s no data migration logic yet and it’s just not going to work!


Different Roles for Translators and Full Translation Workflow

One of the most frequent requests was for WPML to play nice with access limiting plugins. A quick investigation revealed that resourceful users are hacking and building themselves translation workflows.

Until now, everyone had access everywhere. In order to translate, the translator needed to have an Editor account. If you have a team of translators, writers and editors, this is going to cause a huge management problem. So huge that it keeps large businesses from using WordPress.

WPML 2.0 introduces Translators. A Translator is a special user who can only translate. That user doesn’t need to have any sort of editing or writing privileges in WordPress. It can even be a Subscriber.

WPML 2.0 will allow the Admin to send translation jobs to those translators. They can only translate what was assigned to them and nothing more. Translation is done in the new Translation Editor screen, which provides side-by-side translation. When it’s done, WPML builds back the translated content (a page, post or custom type).

This is how it works:

1) The admin goes to WPML->Translation Dashboard and send jobs for translation.

The new Translation Dashboard

You can see the jobs you’ve sent by clicking on the Translation jobs tab:

Translation jobs

Then, your translator logs in to WordPress and this is what he/she sees:

Jobs queue for a translator

Do you see anything special in the screenshot above?

WordPress menu is empty. That’s because this user, Joe, is a mere subscriber. Joe cannot edit or write anything in this site.

WPML give Joe translation rights (well, I did, using WPML). Any jobs that I send in Joe’s language pair are available to Joe.

Joe gets a notification email from WordPress when I send him jobs. Then, he logs in and clicks on WPML->Translations.

He sees a list of jobs waiting for him and can edit any of them. The actual editing is done in the new Translation Editor that comes with WPML 2.0:

Translation editor

The Translation Editor shows the different fields in the document we’re translating. For example, if we’re translating a blog post, we’ll see the title, body tags and categories.

Unlike entering translations manually (as it works in WPML 1.8.3), the Translation Editor asks the translator to translate the texts only.

For example, if the post has tags and belongs to categories, the editor would let the translator translate the tag and category texts. WPML will automatically insert the categories to their correct parent and synchronize everything.

It gets (much) more interesting when custom types and fields are involved. In more complex situations, having to translate only the texts without having to put them into the right place in the GUI is critically important.

This way, the site’s Admin knows that the structure is always correct and translators only translate texts.

Enabling the New Translation Editor for the Inline Editing Controls

Remember those + and ‘edit’ buttons in the list of posts and pages?

You can now tell WPML what to do when you create new translations using these controls. For this, go to WPML->Translation Management->Multilingual content setup.

How to translate

The default is to use the legacy way – e.g., open the ‘edit’ screen and enter translations manually.

To use the new Translation Editor, change the selection and save. Now, whenever you click on the ‘plus’ icon (+), you go to the Translation Editor for side-by-side translation.

Creating Translator Accounts

Joe, from our previous example is a translator. To create Joe’s account, you need to go to WPML->Translation Management->Translators.

Click on ‘Add translators‘, choose the language pair and where you’re getting translators from.

Adding a translator

You can make WordPress users into translators (like Joe) or get professional translators from ICanLocalize.

Language Configuration for Themes and Plugins

The second major addition for WPML 2.0 is that plugins and themes can auto-configure it.

I best dive into an example to show what this does.

SEO plugins use custom fields for the title, description and other SEO goodies. For example, take Yoast’s new SEO plugin.

Editing with Yoast SEO plugin

WordPress SEO uses custom fields in posts and pages for SEO metadata. It also stores many entries in the wp_options table, which are the global SEO texts.

When you run a multilingual site with this plugin, everything needs to be translated, including the SEO metadata.

A single tiny XML configuration file tells WPML everything it needs about this plugin. For reference, here is the language configuration file for WordPress SEO.

Once we activate the plugin, it auto-configures WPML and tells it which fields and Admin texts need translation. Let’s look again to the Multilingual content setup in WPML.

Language setup with SEO fields

As users, we shouldn’t care much how magic happens. The important thing is that it does and we don’t need to facilitate it.

When you use WPML with any plugin or theme that includes a language configuration file, there’s no configuration. Nada.

How is it working for you?

First, thanks for making it this far. If you just skipped to the bottom, it’s fine too.

Let us know how WPML 2.0 works for you. You’re welcome to leave comments here or post issues in the bug tracker.

17 Responses to “WPML 2.0, Beta 2”

  1. Hello Amir,

    Great work on WPML 2. After reading the post I have 2 questions:

    – how will the new translation tool (side by side) work with HTML? When using Translation Assistant currently, each text inside HTML tags were split out and translators would translate each bit. It seems the new side by side only has one large Textarea. Will translators copy paste the original HTML to translate the text inside it?

    – Assume a WordPress Translator user has translated a page, and the translation has been “validated” and appears on the website. Will it be possible for me (admin user) to send all existing translations (eg. Spanish translations) to another translator for ‘review’? In most cases, the original english text wouldn’t have changed but I am basically trying to have all translations reviewed at least twice (which is our quality guidelines for private translators).


    • Translators can copy from the original to the translation. The translation editor is the same TinyMCE editor in WordPress. You can use it in HTML or Visual mode.
      I think that we should have a button to copy the original onto the translation. I’ll check with Mihai if he can slide it in.

      We want to add a proper review process. For now, it’s not in the plugin. We’re pretty happy to have managed to include all the new functions in WPML 2.0, as it is 🙂
      I’m adding this to our near-term todo list and we’ll see what’s possible.

  2. Hi Amir,

    I’m realy anxious to try this new improved WPML. Unfortunatly I don’t have time and/or a beta environment to test your Beta2… So I’ll have to wait for others to help testing stuff for you.

    For now I would like to find more details about the new “XML configuration file”. I would very appreciate to find a technical “How to” tutorial in your documentation so I could prepare this file for whenever WPML 2.0 goes public.

    Thank’s for the great (GREAT!) work your doing with your plugin… and the entire WordPress community.

  3. Hello,

    I am testing WPML 2 beta actually. Great improvement, specially the language configuration file, as I am testing it on a deep child theme customization.

    Everything works fine, I have a custom post type with some custom fields and I was able to configure what is copied when we create the translation of a record, what has to be translated and what is ignored.

    The only thing I don’t get, is that I also have 2 custom taxonomies, both translated, and I can’t manage to “copy” them from one version of the record to another.

    Let me explain: my main language is French, secondary is English

    I have a custom post type “product” that I use to store a small catalog of items for an online show room.

    I have some custom fields (SKU, price, stuff like that)

    I have 2 custom taxonomies, brand and section.

    These taxonomies are translated, and each item I create in French has one section and one brand linked to it.

    When I click on the + button to create a translation, custom fields are copied as I want, title, excerpt and description are set for translation, featured image is copied as I configured, but there is no way to have the translated item get the same brand and section than the original.

    Any guess?



    • WordPress doesn’t allow having two categories with the same name.

      The translation can’t have the same name as the original. It’s just the way WP database is set up.

  4. Sorry, i wasn’t clear.

    When I say “copy” the category, I actually mean taking the translated version of it.

    As an example, if I have an item in the “Cooking” section, this is named “Cuisine” in french and “Cooking” in english.

    If I create a new item with the category “Cuisine”, when I click on the + button, I’d like the translated item to automatically have the “Cooking” category, see what I mean?

  5. Impressive work guys.

    The killer feature for me, is the ability to configure the translation of plugin custom fields. In my situation, some of the custom fields contain dates/numbers. Therefore they don’t need to be translated and it’s inefficient to re-enter everyone of them in every translations. On the other hand, some of the fields contain place and people names, which need to be translated.

    However, knowing that it works for the normal custom fields, it doesn’t for the Geo Mashup ones. The location info doesn’t seem to be transfered to the translation posts.

    • This would take debug work to check why Geo Mashup fields don’t get translated.

      If the author of that plugin is interested, we can work on it with them. Otherwise, we can do it as a paid consultancy job.

  6. Hmm.. I’ve just noticed now that the field values for the translated post are copied from the original post as if you manually entered them. That means, you have to re-save the translated post everytime you make changes on one of the custom field values of the original post so the plugin takes the new one, which isn’t efficient at all.

    Cannot this behavior get changed to something like syncing?

  7. Can that modification be done as a paid work, without exclusive rights (so it’s implemented in the core and anyone can use it)?

  8. Am I the only one having trouble with a corrupted zip file? Would really like to check out compatibility with my site…