WPML keeps strict separation between languages. Every post or page is unique in the database and includes content in its own language only.

When switching languages, WPML displays only content in that language.

This means that the site’s navigation will show only pages, categories and posts in the current language. If you switch to content in another language, the language switches and now you see the navigation in that language. Clicking on other links will lead you to content in the other language.

Different Languages for Content and Navigation is Problematic

Folks have asked us to allow showing content in one language but keep the navigation in another. This is super-problematic and we don’t see a way to do it.

It means hooking to a gazillion places and making WordPress think it’s on a different page than it actually is. It will add a huge amount of code and increase the number of database queries significantly.

Instead – Auto-Duplicate Untranslated Content

While we can’t show content in one language and navigation in another, we can certainly duplicate content to all languages. This is what I’m thinking about:

• The Translation Dashboard screen will have a new button for duplicating content. Instead of just ‘send to translation‘, it will also have ‘duplicate content‘. This means that you can use all the filtering power of the Translation Dashboard to choose what you want to duplicate.
• When you duplicate content, WPML will automatically adjust links in the duplicated posts and pages. This means that inline links will retain the current language.
• WPML will show duplicate and translated content differently. This way, if you later decide to translate content that you duplicated, you can still locate it and send to translation.

We will also a way to tell WPML to auto-duplicate new or updated content. This will save you the hassle of going through the Translation Dashboard every time you create or change something.

Pros

There’s no performance penalty – all this operation is done in the WordPress Admin once, and not every time visitors come to your site. For me, this is the major advantage.

It will work – this change doesn’t require any additional filtering or hooking and is not sensitive to future changes in WordPress. It’s also theme-friendly.

It’s selective – you decide which content to duplicate and when.

Cons

It’s not a fully automated solution in the sense that you tell WPML to do it once and it just happens.

Duplicate content will sit in your database and increase its size (but it’s not as bad as it sounds). The WordPress revisions system takes far more memory than this and is not a big deal either.

What do you think?

This is a fairly big job and we’ve been hesitant about it. Now that we have more developers, we can tackle greater challenges.

Before we jump on this, I’d like to see what you’re thinking and make sure that we’re not forgetting anything. Leave your comments and lets see!

People who are not familiar with CAT tools deserve a short intro. You can skip it.

We’re not talking about the cats that chase mice, but about Computer Assisted Translation tools. These are programs that help translate better. Better means:

• More accurately
• More consistently
• Free from technical errors
• More efficiently

CAT tools include translation memories, taxonomy management and neat editors. They let translators concentrate on translating, without having to deal with technical issues.

For example, when translating HTML, translators will not have to deal with markup. They would translate just the texts and the tool will build the valid HTML.

When translators see sentences that they already translated, the tool will remind them what the previous translation was and offer to apply it quickly. It will also remind the translator how important terminology is translated.

Most professional translators have their own CAT tools (e.g., which they purchased) and they use them to in order to be more efficient and earn their living easier.

CAT Tools, WordPress and WPML

As we all know, WordPress holds pages that contain HTML. WPML helps translate those pages by typing in translations to new pages.

To work efficiently, translators need to use CAT tools. These tools will speed up the work and make it better. Translations done using CAT tools will be more accurate than those done by manually typing in text.

Today, in order to use CAT tools, translators need to go to HTML mode, copy the text and paste to their CAT program. They need to manually handle other fields such as title, categories, SEO fields and tags. For larger sites, it proves to be a lot of work.

WPML 2.1 will include an interface to CAT tools via XLIFF files. XLIFF is a universal format for translation. An XLIFF file includes all fields for translation, the text and existing translations.

When translators get XLIFF files, they open them in their CAT tools, work in their favorite environment and save.

Then, they will upload the XLIFF file to WordPress and be done with it. No manual copy/paste, no room for technical error and everything taken care of. Translators only translate and waste no time on anything else.

Which CAT Tools Are You Using?

Seems like we’re back where we started. Now that we know why CAT tools are such a great thing, help us by telling which CAT tools you, or your translators are using.

If you’re using a translation service, send them an email and ask them to comment here. The more people answer, the better we know which tools to support.

Leave your comment with the type of CAT tool and the version you’re using.

WPML 1.8 menu

A bit scary, isn’t it?

It’s not entirely our fault. WPML adds languages, translation process, theme localization, CMS navigation and Sticky links. You can also get support directly from it.

Lots of functionality…

But, when you think about it, almost everything here is for the web developer building the site. The user only needs to manage translations and maybe add or remove languages. Maybe.

The rest, you use when you configure the site. You don’t expect users to change the language negotiation or enable / disable Sticky links.

Today, WPML includes Basic and Advanced modes. Basic mode includes the more frequent and less technical features in WPML.

When your client is running a complex WordPress site, most chances are you’re using everything WPML has to offer. Your clients, however, don’t need to see all this complexity. They just need to administer content, including translating it.

Developer Vs. User Modes

Developer mode would be like the current Advanced mode. All of WPML’s features and menus are visible.

User mode will be crafted for content admins. We’ll introduce it in WPML 2.0.

In User mode, WPML will include only the Translation Management. This will allow users to translate contents, or send contents to translation services. There would be no clutter, but only features that content admins need.

These features will include:

• Assigning Translator privileges to users (new in WPML 2.0)
• Using the Translation Dashboard to send documents to translation (enhanced in WPML 2.0)
• Viewing the Translation Jobs Queue (yeah, also new in WPML 2.0)
• Editing translations via the Unified Translation Editor (completely new in WPML 2.0)

The rest of WPML’s features, will only be accessible in Developer mode. Users can easily switch to that mode, but then, they shouldn’t complain about being overwhelmed with options. That’s how it is.

Just WPML?

As I write this post, I realize that we’re not alone. WordPress 3 is a fully featured CMS. Different User and Developer modes would have been useful for WordPress itself, for many themes and for many plugins.

Who knows? maybe someday…

Just a year ago, people used WordPress mainly to build blogs. Most themes were blog-oriented.

Then, came magazine themes and now we’re seeing more and more product-related sites. This explains the gold rush of E-Commerce for WordPress.

But, as things become more complex, getting it fully multilingual is turning very difficult.

For example, how would you handle these?

• Indicate which custom fields need translation
• Choose which custom post types and taxonomy to translate
• Choose which admin strings (stored in wp_options) to translate
• Restrict access for translators to their languages
• Send notification to translators about new work
• Keep track of translation progress

With the current design of WPML, all these questions are difficult to answer.

Full Integration with Themes

WPML 2.0 will read a translation configuration file from the theme. This configuration file will tell WPML everything it needs to know about making the theme multilingual.

It will be a simple XML file, which both humans and WPML can easily read. So, instead of having to go through dozens of check-boxes and menu options, the theme can come prepared with its multilingual settings.

When people use themes that include translation configuration files, they can start translating immediately. No changes to do and nothing to set up (except choose your languages).

As a great example, keep a close eye on Templatic‘s E-commerce framework. We’re working closely with the developer to make E-commerce multilingual ready as soon as WPML 2.0 is ready.

Working with Translators

So, once we’re using a theme with a translation configuration file, we’ll need to manage the translation process itself.

As site developers, this may seem like a small problem (to the content admins), but we’re actually talking about a huge challenge for your clients.

With single-language sites, you need to train the client about how to use WordPress. When you deliver multilingual sites, you need to teach the client and the translators. Clients may have good technical background but most translators are way behind. They know translation tools inside and our but have no idea what WordPress is.

To solve this, we’re separating between site admin and translation. Completely.

As it works today, admins click on these cools + buttons and add translations. That’s great. It just gets a bit more work when they also need to match categories, tags, custom fields and parents.

Then, when you’re also using custom post types, the translators will need to manually scan posts, pages, tags, categories and all custom types to find what’s changed. That’s a lot of work for someone who doesn’t know WordPress.

Again, WPML 2.0 changes all that.

Everything that needs translation will appear in the Translation Dashboard.

The new Translation Dashboard in WPML 2.0

This page is for admins only (not translators). Admins choose what to translate, to which languages and by who.

Then, they click on the button to send to translation.

WPML will send notification emails to all translators, telling them about the new work. It will include a link to the translation jobs queue.

When translators click on that link, they see a list of jobs waiting for them. Each translator sees the jobs in his/her language pair.

Translators click on each job and arrive at the Unified Translation Editor.

The Unified Translation Editor in WPML 2.0

* This screenshot is a bit outdated. The editor will include WYSIWYG editors for all text fields

Translators don’t really need to care what they’re translating. They use a special translation editor where they translate everything.

The editor shows the original text and the translation side-by-side. They complete the translation and click on Save.

Then, WPML puts everything back into place.

Remember that translation configuration file that the theme includes? This is how WPML knows what needs translation and where to return everything.

Translators don’t need any privileged in WordPress to translate. They don’t even need writer or editor rights. Site admins choose which language pair they can translate between and WPML takes care of everything else.

Want in Too?

We’re building this fancy new translation system based on great user feedback.

If you’re building themes, leave a comment here. We’d love to work with you towards WPML 2.0 and make sure that it covers everything that your theme can do!

1. Are you using WordPress MU right now? If so, what for?
2. Already tried the MultiSite feature in WP3.0? Is it working for you?
3. To run truly multilingual, what would you need WPML to do on multi-site installs? (a detailed flow would be great)

When?

Our schedule for WordPress 3.0 support goes like this:

• This week, add support for custom post types.
• Until the end of May, add support for multilingual menus.
• Then, we’d like to go after MultiSite support.

Speak out and get involved in the design. This time, we need more than testing. We want you to help build the right features for multi-site support.

Menu system

One of the best things about WordPress 3, came from WooThemes. It’s the new menu builder system.

Instead of getting menus auto-generated according to page IDs you can now control exactly what appears in your site’s menu. This includes mixing pages and categories, dragging things to their places and controlling their order. It’s cool.

A multilingual site will surely need a multilingual menu and there are two approaches to it:

• Separate menu per language
• Translation for menu items

While each of these alternatives has its advantage, we’re leaning towards a single menu with translated items. We still have to check and make sure that WordPress has all the hooks in place to allow WPML to translate menu items, but if that’s the case, it would probably be easier for folks to use.

What will happen is that you manage the menu for the default language and WPML will allow translating the different menu items. If an item is for a page, the menu item will just include the title of the page’s translation. If you’re entering titles manually, you’ll use WPML’s string translation to translate these titles.

What would you like to see? If you’ve already built sites with the Woo menu generator do you have ideas about translating them?

Custom post types

Many (including ourselves) consider this to be the most important feature in WordPress 3.

If you’re using WordPress for a blog, you’re not going to notice this feature at all. However, anyone building complex sites with WordPress will appreciate this features right away.

For example, building our showcase would have gone much simpler if we could define custom showcase pages. It would eliminate the need to use a special template and enter details in custom fields.

WPML should support custom post types just like the current WordPress posts and pages. You’ll have the language box there and can determine the language and translations.

However, some issues are still open.

Posts and pages have a fixed structure and we could hook to their pages and add WPML’s magic. We’ll have to be a bit more flexible when dealing with custom types.

Have you tried custom post types on WordPress 3 Alpha? Any ideas about language support for it?

Custom taxonomies

WordPress already has custom taxonomies today, but very few folks use them. WP3 promises to make custom taxonomies easier to use. Along with custom post types, I think we’re going to see a huge rise in the popularity of both.

Right now, WPML doesn’t translate custom taxonomies at all and we’re going to work on that for WordPress 3.

Ideas anyone?

We’ve just started to scratch the surface with WordPress 3. If you’ve already studied it better, let us know.

New features in WPML 1.6.0

WPML can translate other plugins too

WPML can now translate everything in your site, include other plugins. You can do that without asking for any .po file, begging the developers to upload translations or anything else.

Just head over to WPML->Theme and plugins localization.

There, you’ll see a list of all your plugins. Click on the check-boxes next to them and WPML will scan them for texts. In so doing, it also imports all existing translations from any .mo files.

Now, you can continue editing yourself. Click on the Translate button, next to each plugin and you’ll land in WPML’s string translation page. You can translate any text to any language without having to go through those dreaded .mo files, poedit or any other barrier.

Know what you’re translating

Ever wonder what “%1 in %s” means when you’re translating?

WPML now shows you where texts come from, both in the PHP source and in the HTML.

Next to each string you’ll see two icons (when available). When WPML scans the PHP, it keeps track of where the texts for translation come from and will show it to you when you’re translating. Now, you can see exactly where in the source strings appear and (if it manages to find it), WPML can also show where in the HTML.

Bugs fixed

Yeah, bugs are a part of life, but we shouldn’t get used to them. Instead, it’s better to report them in the forum.

And since we’ve got great users who report problems and take their time to explain them to us, we can also fix bugs as they’re discovered. These bugs were fixed in WPML 1.6.0:

• Language fallback for blog posts had a bunch of bugs (broken search, incorrect category pages and tag). They’re all fixed now.
• Added placeholder for _cleanup_header_comment (for compatibility with WP 2.7 and below).
• Fixed some bugs with the tags and the tag cloud.
• Fixed bug with missing comments.
• Added correct Estonian flag.

So, keep those reports coming and we’ll do our best to fix problems as fast as we can.

If you missed it before, this is the download link: WPML 1.6.0 RC1

BTW – we think that this version is good enough to power production sites. It’s live now on our own WPML.org and icanlocalize.com.

• Only posts that have translation.
• All posts – if there’s translation, show it, otherwise, show the post in the default language.

Our site includes pages and posts. We’re translating almost all pages, but very few posts. Now, when folks sign up to our German feed (for example), they’ll get our news in German, if they’re available and otherwise, in English.

This new feature applies only to blog posts and RSS feeds. There’s no language fallback for pages and we’re not planning to add it (for reasons such as site navigation integrity, parent/son relationships, etc.).

Want to try this new version?

Not so fast. This new version is tested very basically and has some work-in-progress functionality.

By any means, don’t install it on any live site. It’s just for testing on local test sites.

OK? No live sites please. So, here’s the download link – sitepress-multilingual-cms1.4.1.dev-2.zip

Like any time you update a plugin manually, remember to deactivate and activate it again after you install the new version.

To enable this feature, go to WPML->Languages. It’s under More options (available only in Advanced mode).

New blog posts filter in WPML 1.4.1

Creating a test version of your site

This is a bit unrelated to this particular version, but I think it’s going to be useful to read anyway.

It’s always a good idea to have a local version of your complete site and test things on it. This is how we create local test versions for our sites:

1. Install Apache, PHP and MySQL. If you’re on Linux or Mac, it’s already there. For Windows, you can use XAMPP.
2. Create a local domain by editing your hosts file. On Linux it’s /etc/hosts. On Windows – C:\Windows\System32\drivers\etc\hosts.
3. Create a MySQL database and install WordPress locally.
4. Copy the entire wp-contents directory from your online site to your local test site (use ZIP to finish this before Christmas).
5. Do a database dump of your live site. You can do that using phpmyadmin or using mysqldump from an SSH command line.
6. Download the dump and edit it. Replace all places where your online domain appears with the local domain. There should be thousands of places to replace.
7. Import the database dump to your database. It’s easiest using a command line: mysql -u USER -pPASSWORD DB_NAME < DB_DUMP_FILE

Everything should look the same on your local test site, except you’re browsing your site locally from backup. It runs faster and can’t cause any damage.

Install whatever it is you’re testing in the local site and check it. If everything running smooth you can also install on the live site. Problems? No harm done, you’ve only messed the test site and you can import the database and try again.

Of course, this setup only needs to be done once. It’s a good idea to keep that local test site handy for the next time you’re trying something new.

Having said this, even if this current version of WPML runs flawlessly on your test site, please don’t install it on any live site. We’re going to add some migration logic to it and it will be very difficult to apply if you update now.

Let us know what you think

Like the new blog language fallback? Any problems, suggestions or ideas? Leave a comment here.

And, have a good weekend! I’m off, for my.

In addition to letting users manually enter their own language switcher colors, we’re going to include several preset color schemes to choose from. The preset schemes we’re thinking about are:

• White
• Gray
• Blue

Would you like to contribute a color scheme?

Here’s your chance. We know we’re not the best graphics artists, but many of you are!

Leave a comment here, including the CSS for WPML’s language switcher and a link to a screenshot showing how it looks in practice. We’ll choose the nicest ones and include in the next release of WPML.

For reference, here is WPML’s default CSS for the drop-down language switcher (taken from res/css):

#lang_sel {height:32px; position:relative; z-index:99;  font-family:arial, sans-serif;}
/* hack to correct IE5.5 faulty box model */
* html #lang_sel {width:12em; w\idth:12em;}

/* remove all the bullets, borders and padding from the default list styling */
#lang_sel ul, #lang_sel li {padding:0 !important; margin:0 !important; list-style-type:none !important;}
#lang_sel li:before{content:'' !important;}
#lang_sel ul ul {width:149px;}

/* float the list to make it horizontal and a relative positon so that you can control the dropdown menu positon */
#lang_sel li {float:left;width:149px;position:relative;}

/* style the links for the top level */
#lang_sel a, #lang_sel a:visited {display:block;font-size:12px;text-decoration:none !important; color:#fff; border:1px solid #000; background:#09c; padding-left:10px; line-height:18px;}

/* a hack so that IE5.5 faulty box model is corrected */
* html #lang_sel a, * html #lang_sel a:visited {width:149px; w\idth:138px;}

/* hide the sub levels and give them a positon absolute so that they take up no room */
#lang_sel ul ul {visibility:hidden;position:absolute;height:0;top:19px;left:0; width:149px;border-top:1px solid #000;}
/* another hack for IE5.5 */
* html #lang_sel ul ul {top:18px;t\op:19px;}

/* style the table so that it takes no ppart in the layout - required for IE to work */
#lang_sel table {position:absolute; top:0; left:0; border-collapse:collapse;;}

/* style the second level links */
#lang_sel ul ul a, #lang_sel ul ul a:visited {background:#eee; color:#000 !important; height:auto; line-height:1em; padding:3px 10px;border-width:0 1px ">1px 1px 1px;}

/* yet another hack for IE5.5 */
* html #lang_sel ul ul a, * html #lang_sel ul ul a:visited {width:150px;w\idth:128px;}

/* style the top level hover */
#lang_sel a:hover, #lang_sel ul ul a:hover{color:#000; background:#ccc;}
#lang_sel :hover > a, #lang_sel ul ul :hover > a {color:#000; background:#ccc;}

#lang_sel a.lang_sel_sel{
    background:url(../img/nav-arrow-down.png) #09c right no-repeat;
    color:#fff;
}
#lang_sel a.lang_sel_sel:hover{
    text-decoration: none;
    color:#000;
}

/* make the second level visible when hover on first level list OR link */
#lang_sel ul li:hover ul,
#lang_sel ul a:hover ul{visibility:visible; }

#lang_sel img.iclflag{width:18px;height:12px;}

So, just before diving in to the first theme multilingual packs, we’re ready with another bugfix release:

WPML1.4.0.4_dev

Who should upgrade

If you’ve reported an issue in the forum, most chances are that a fix is included in this version (have a look at the bug-fix details).

One of the most popular problems we’re seeing is with initial setup. All sorts of issues keep the AJAX calls from running correctly. Since it’s done in AJAX, debug can be quite difficult. We’ve added a health check for the AJAX calls, so that when WPML has a problem, you’ll know about it right away.

If you can’t add languages, try this version and see if it explains why.

Also, if you’d like to experiment with the new features and get back to us with feedback, it would be great if you can try this new version.

How to upgrade

1. Download the devel version to your wp-contents/plugins directory.
2. Unzip it there.
3. Deactivate WPML and activate it again.

Fixes and new features

The aim of this version isn’t to add too many new features (and possibly new bugs), but to fix existing problems. On the way, we also added some simple features, who made running some sites (including our) difficult.

Fixed bugs

• Improved the way the AJAX functions are loaded – helps for non-standard server configurations.
• Reports a 404 error for missing translations (and not a weird unrelated message).
• Makes sure that translations can never be sent to ICanLocalize twice.
• Added health check for AJAX files (and warns if anything appears broken).

New features

• Users can add notes for translation (when using ICanLocalize translation).
• Breadcrumbs function accepts custom separators.
• Professional translation setup screen re-ordered to be more streamlined.
• Added custom fields for integration with iPhone and BlackBerry applications.
• Page template, ‘allow comments’ and ‘allow pings’ synchronized between translations.
• ICanLocalize reminders box can be minimized.