When search engines go through a multilingual site, they need to understand which parts are in what language. This way, visitors get search results matching their own language.

Google wants to return pages written in the user’s language. When a German reader is looking for something in English, often, Google would prefer to return German pages that talk about the same thing.

For this to happen, search engines need to know how your site’s languages are organized. Google looks at the big picture. It doesn’t care only about individual pages in the site, but how they are organized and the ‘big picture’ of what your site is all about. This includes its languages.

Language Negotiation Options in WPML

WPML allows organizing contents in different languages in several ways:

• By adding a language parameter to URLs (example.com/?lang=es)
• By putting different languages in directories (example.com/es/)
• By putting each language in a different domain or sub-domain (es.example.com or ejemplo.es)

You can control this from WPML->Languages menu.

Language negotiation options in WPML

SEO Implications

From an SEO point of view, the first two alternatives are very similar. All languages will remain on the same domain, separated by either a language argument or language directory. The third option allows to place different languages on different domains. You can use that as either sub-domains (like www.example.com, es.example.com) or as completely different top-level domains.

Some say that Google local search loves localized top-level domains. Others say it doesn’t matter much and Google is intelligent enough not to care.

What are you doing for your site? Take the poll and leave a message with your experience and results you’re seeing.

I’ll be the first to go. On both WPML.org and ICanLocalize.com, we use language directories. E.g., the same domain for all languages. My bet is that the 50,000 Ph.D’s working for Google are smart enough and I cannot manipulate search results with a simple technical change. Hey, I can be wrong!

As WPML 2.0 is getting ready, we’re already looking forward to the next big leap. If you’re using teams of translators, or a translation service, they surely care about working efficiently. CAT tools are the way. They allow cutting down translation time and improving translation accuracy.

Translator who use CAT tools can see how the same expression was already translated before and produce consistent work. They work faster and produce better results.

WPML 2.0 makes it very easy to send content to translation. WPML 2.1 will complete the picture by simplifying the translation.

Tell us how you and your clients use CAT tools

We want to know how you and your clients are managing the translation work. The more we know, the better we can build it for you.

Take your time, send a few emails to your clients and help us get as much data as possible.

Maybe I best start with an example.

Property Listing Site

Supposing you’re building a site that lists properties and you want it running multilingual.

With WordPress 3, the correct way to build it would be by using custom post types for properties and custom taxonomies. Shared attributes (like zone and type) would use custom taxonomies and specific attributes, like price and location, would use custom fields.

Your client will add properties to the site and now it needs to be translated. This is where things get interesting.

How is the translator supposed to know how to operate this? It’s one thing having to train the client, but now you need to teach WordPress administration to several translators.

Meet WPML’s Language Configuration Files

WPML 2.0 will allow themes and plugin to tell it what needs translation. Now, your properly listing file can tell WPML that the ‘properties’ type is multilingual, that it needs to copy the ‘price’ and ‘address’ custom fields to translations and that the ‘zone’ custom taxonomy should be translated.

Translators will not need to know anything about WordPress in order to translate. When the admin sends properties to translation, WPML will collect all the relevant fields and taxonomy and send to translation. The translator will translate them as text fields and WPML will create back everything in WordPress.

For this to work, WPML will need to find the language configuration file in the theme.

Language Configuration Files for Theme Frameworks

Fortunately, most sites are not coded from scratch. Developers use theme frameworks as basis.

We’re looking for volunteers to test WPML 2.0 on different theme frameworks and build the language configuration files for them.

We’ll get two things from that:

• WPML and these frameworks will work perfectly together.
• Any theme you base on these frameworks would be extra easy to translate.

It’s good for you and good for your clients. Imagine how much time you’re going to save for your client and for yourself, when WPML knows how to translate the site. There’s nothing more to document or explain.

Which Themes?

For some time now, we’ve been working with major theme design houses to make sure that their themes are multilingual-ready. We’re looking for people to help maintain the language configuration files for Atahualpa, Thematic, Viva Themes, WooThemes, StudioPress and other great themes (see list in the forum thread).

If you’re using any of these themes, or a different popular theme framework, join that thread. In the forum, we can paste code snips and XML contents, so we can exchange information easily.

You’ll get to work with WPML’s developers directly, improve WPML and make it work much better with your theme frameworks. What are you waiting for?

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!

CMS Tree Page View shows WordPress pages as a tree, instead of a (useless) list. You can expand and collapse branches and move pages around. It’s a very useful feature if your site is made up of pages and not only blog posts.

Until just last week CMS Tree Page View had no concept of language. All pages were created the same. Pär and I talked and decided to change this. By adding a language selector to the Tree Page and applying the standard WordPress filters, CMS Tree Page View now works multilingual.

You can choose which language to arrange pages in and the pages tree will include only pages in that language.

This change is not released yet and you’re invited to test it. Grab the development version from here:

http://bit.ly/c2kmdf

Place in your plugins directory, unzip and activate.

Once you do that, you’ll get a new menu under Pages, allowing you to order pages as a tree. This is the original demo video for the plugin (without the language selector yet):

We’d love to get your feedback about CMS Tree Page View. You can leave comments here or directly in Pär’s site.

Just Pages?

For now, CMS Tree Page View works on pages only. Pär says that soon, there will also be a version that supports custom types.

EDIT: This Beta version already supports custom post types!

It was really fun building icanlocalize.com using WordPress. The visual editor and media management make it easy to get contents online quickly. But, like many newly weds, after the initial excitement, real problems begin surfacing.

Custom Types Turn WordPress into a CMS

A content management system lets you edit contents without having to worry about how these contents appear on the page.

For example, have a look at this website translation page:

Page with different elements

This page includes:

• Navigation
• Page title and body
• Testimonials

We wanted testimonials to automatically appear in the right pages. For instance, this page only includes testimonials of clients who use our website translation service. Other testimonials that talk about iPhone localization, don’t appear in this page. They would appear in the iPhone localization service page.

Until WordPress 3, you could build this using pages and custom fields. That’s great, but causes a big mess. It’s difficult to set up and even worse to maintain. And, it gets much worse when running multilingual.

Now, it’s all clear and simple. Let’s start with the setup.

Adding Custom Types from the Theme

Since the testimonials type is added to our site, the place to declare them is in the theme. All it takes is this code:

register_taxonomy(
  'service_type',
  array('post', 'page'),
  array(
    'hierarchical' => true,
    'label' => 'Service type',
    'query_var' => true,
    'rewrite' => true
  )
);

register_post_type( 'testimonial',
  array(
    'description' => __( 'Testimonials.' ),
    'labels' => array(
    'name' => __( 'Testimonials' ),
    'singular_name' => __( 'Testimonial' ),
    'add_new' => __( 'Add New' ),
    'add_new_item' => __( 'Add New Testimonial' ),
    'edit' => __( 'Edit' ),
    'edit_item' => __( 'Edit Testimonial' ),
    ...
  'taxonomies' => array('service_type'),
  ...

Once we’ve added this to the theme, we get a new Testimonial section in the WordPress admin.

Admin menu with testimonials

Displaying Custom Types in Standard Pages

So now, we were able to create testimonials as a new type. We’ve even added a service-type tag which says what the testimonials are about.

Next, we need to actually display the testimonials in pages.

We will collect all the testimonials that before to each service type and add them to that page.

What we do is:

$query = array('suppress_filters'=>0, 'post_type'=>'testimonial',
   'service_type'=>$terms[0]->slug, 'showposts'=>$number);

And, we’re done. Each page would automatically display all the testimonials for the service it talks about.

Multilingual, Out of the Box

WPML creates copies of the data in each language and associates them as translations. If you’re translating a testimonial, you’re actually creating another testimonial page in a different language. WPML assigns the language values and joins all translations together.

When our code requests the testimonial for a given service-type, it will automatically get them in the right language. This is because the service types are translated too and each translated page is automatically associated with the service type in the right language.

This may sound a bit complicated, but it all happens behind the scenes. In practice, you don’t need to do anything. Just translate everything and things ‘magically’ display in the right language.

Teaser – Using Views to Display Custom Data

In order to display testimonials on each page we had to write a piece of PHP code as a plugin. We love PHP and do it all day, but not everyone is like that.

Wouldn’t it be great if a plugin could display custom data in flexible ways? We’d like to be able to paginate, sort and do all sorts of basic operations.

We’ll supply the HTML / CSS and the plugin would get us the data to display.

Drupal folks are already giggling. It’s called Views – one of the most popular Drupal modules.

We’ve already started working on Views for WordPress. There’s no release yet, so this page doesn’t even exist, but it’s getting there. Once we’re done adding support to all the cool new features of WordPress 3 for WPML, we’re getting back to Views.

GetText is a GNU’s text localization package. It allows replacing text in one language with texts in another language.

We’ve already talked about using GetText to build multilingual themes. Now, we’ll talk about how to make the theme’s texts translatable, from the translator’s point of view.

Complete sentences only, please

Translators cannot accurately translate single words. They need to see the entire sentence in order to translate correctly.

For example, what does You must be mean?

In English, the word be has one meaning. But, in Spanish, be mean what you are (ser) or where you are (estar). There’s no way a translator can translate this correctly without seeing the entire sentence.

This is the code that’s responsible for the text:

<?php _e('You must be') ?> <a href="<?php echo get_option('siteurl'); ?>/wp-login.php?redirect_to=<?php echo urlencode(get_permalink()); ?>"><?php _e('logged in') ?></a> <?php _e('to post a comment.') ?>

So, what do we do?

Using full sentences with placeholders

What we’ve actually done in this example is concatenate several parts into a sentence. The way we did it broke the sentence into different pieces, losing all meaning in the process.

Here is this same thing, built with a single sentence a placeholder:

<?php printf(__( 'You must be <a%s>logged in</a> to post a comment' ), ' href="'.get_option('siteurl') . '/wp-login.php?redirect_to=' . urlencode(get_permalink()) . '"') ?>

What we’ve done is:

1. Create one large text that includes a placeholder.
2. Use printf to replace the placeholder with an actual value.

The translator now needs to translate this sentence:

You must be logged in to post a comment

The translator can easily translate this entire sentence.  No questions to ask and no problems translating!

Besides being easier to translate, we need to remember that in different languages words appear in different order. Supplying the complete sentence with placeholders will allow the translator to flip the order of words and produce grammatically correct (and sensible) transaltions.

Really advanced case (appears in every WP site)

Look at this PHP code. It appears in almost every WordPress site in the comments section.
<h3><?php comments_number(__('No Responses'), __('One Response'), __('% Responses') );?>
<?php _e('to') ?> &#8220;<?php the_title(); ?>&#8221;</h3>

The translator would have to translate the word to. But, it’s impossible without understanding how to is used in the sentence.

The word to is part of a sentence, which would be:

3 Responses to new widgets

Once the translator sees the entire sentence, it all becomes clear and easy to translate.

To turn this into a single sentence, we’ll use this PHP code:
<h3><?php printf(__('%s to %s'),
get_comments_number_ml(__('No Responses'), __('One Response'), __('% responses') ),
'&#8220;' . get_the_title() . '&#8221;')?></h3>

This code produces a full sentence to translate. Now, the translator can produce correct translation to your comments heading.

Note: we’ve replaced the standard WP get_comments_number with an identical function that returns the comment count as a value and doesn’t echo to the screen. You can download this PHP code from get_comments_number_ml.zip.

What about your themes?

Are your multilingual themes built for correct translation?

An easy way to test is to open your .po file in poedit and review the strings. If you’re seeing anything that isn’t clear by itself, look for it in the source and revise.

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.

Update (April 3, 2011): WP E-Commerce 3.8 is out and it looks like it works fine with WPML. Test it and let us know how it’s going.

A week ago we wrote about sponsoring support for niche development and now we’re getting ready start with the first multilingual e-commerce solution for WordPress.

Three folks – Nicolas Harnois (2 Associés), Dan Milward (WordPress e-Commerce Plugin) and Level Level have agreed to sponsor this work.

Since we have an interested co-sponsor, we’ll naturally be starting with WordPress e-Commerce.

What’s a multilingual e-commerce solution?

An e-commerce plugin is like a CMS inside a CMS. It has its own database with products, shopping carts and transactions. Going multilingual means that products need to have language attributes and be translatable.

Then, the entire shopping, checkout and delivery process needs to run in the language in which the product was viewed.

Of course, people would also need to be able to pay in different currencies. That’s not exactly language related, but still should be supported.

How

WPML includes a mechanism for hooking to other plugins.  We call it compatibility packages.

The idea is that the e-commerce plugin continues working the same in one language. When WPML also runs, it will use hooks and filters in the e-commerce plugin to add the language information. This is exactly what WPML does with WordPress core as well.

On the e-commerce plugin side, we’ll need to make sure that there are filters in place for adding the language attributes. For instance, WPML needs to add language selectors to product pages, and translation controls to product administration.

Once all these filters and hooks are in place, WPML can make any plugin fully multilingual, just for the users who need it. Makes sense?

When

We got word that WP e-Commerce is updating now. We’ll work together with the folks from Instinct to make this new release multilingual-ready. We’re very excited about this and can’t wait to get started!

If you’re running an e-commerce WordPress site and want to see it running multilingual, let us know. We’ll be looking for early adopters to test and give feedback.

Site languages versus admin language

WPML allows WordPress sites to run in different languages. This means that one language becomes the default language and other languages are added. So far, nothing new.

By default the default site language is also the admin language.

Without WPML, you can set the site’s language by setting the WPLANG variable in wp-config.php. When WPML is enabled, the WPLANG variable is ignored. Instead, WPML sets the site’s languages.

Visitors see the language according to the page they’re viewing. Admins can choose in which language to administrate WordPress. The default is to have the same language, but it can be changed.

Choosing a different Admin language

First, you need to put WPML into Advanced mode. To do this, click on Go Advanced at the top of any page in WPML’s menu.

Go to WPML->Languages. Then, scroll down to where it says Admin language.

Default admin language setting

You can choose any of the site’s languages there. Once set, WordPress admin pages will appear in that language, unless users select a different language for themselves (up next).

Individual admin language per user

If you’re running a multilingual site, it’s very likely that different authors would like to see things in different languages. WPML makes that possible.

Each user should go to the profile page (Users->Your profile). Scroll to the bottom to where it says WPML language settings. There are several settings there and right now, we’re interested in the admin language.

Look at where it says Select your language. The default value is to use the default admin language (which we just set before).

Admin language for each user

This setting is per user and whatever each user selects here doesn’t influence other users. Any user can select the admin language, which overrides the default values.

Making WordPress display correctly for each language

In order for WordPress to display correctly in different languages, you need to have the localization files installed and the correct locale selected per language.

WPML comes with default locales for most languages, but you need to install the localization files for WordPress.

To do this, go to WPML->Theme and plugins localization.

You can choose one of the two options, to use .mo files to translation by WPML. When you will see a table with locale values per language. This table will already include the correct locales, as WPML determines, but you can edit it.

Locale settings per language

WPML shows you if the .mo file for WordPress exists in the wp-includes/languages folder. If it says File exists, it means that WordPress admin will display in the correct language. Otherwise, you need to make sure that the .mo file is in place and that the locale code (Code field) is correct.