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.
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.
You can see the jobs you’ve sent by clicking on the Translation jobs tab:
Then, your translator logs in to WordPress and this is what he/she sees:
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:
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.
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.
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.
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.
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.