WPML versus qTranslateX – a Clear Winner?

All over the world people use multilingual websites so they can get information they want in the language they prefer. Closer to home, in Wales, a large minority of web users prefer to access content in Welsh. For this reason, many businesses and organizations in Wales provide bilingual websites giving their visitors the choice to read Welsh or English.

When building a bilingual website there are different approaches to consider depending on what the project needs.

For WordPress, a popular choice for managing websites, handling bilingual content is done through addon plugins. I tend to use either qTranslateX or WPML. Which one I’d choose would vary from project to project. As well as the project spec, an important decision factor is the experience and preferences of the team involved in looking after the website.

Comparing the 2, on balance I prefer qTranslateX. I’ve used both plugins on a variety of projects and qTranslateX just feels easier. Easier to use and easier to integrate with other plugins – a simpler way of doing things. When I have to do something new with WPML it usually feels like a mission to work out how to do it, whereas with qTranslateX everything’s where you expect it to be. But in the end they both do a great job of managing a bilingual site.

Chalk or Cheese?

A fundamental difference between the 2 plugins is that WPML creates a new post for each translation while qTranslateX uses just one post to hold both languanges. This offers pros and cons with different situations and set ups.

WPML provides a comprehensive framework for multilingual content, and it feels complicated. Translation is done through various interfaces within the framework and it can be confusing to find out where to enter a translation. That said the support team and forums are great, and you’ll find most of the issues people come across are fixable – either by changing or refining the settings, or finding out where something is translated.

To take advantage of all of WPML’s features you need to install a suite of plugins which will allow translation of everything including media items such as images and galleries, and slugs (the URL address of each page). Some of the bigger plugins like WooCommerce, Yoast SEO and Event Manager have plugins that interface with WPML creating extra admin fields for translation.

QTranslateX, on the other hand, uses ‘languange tags’. These tags allow you to add multiple languanges in the same post, or content type (e.g. menu items, custom post types, categories, other taxonomies). So adding a translation is done there and then on the same screen. Most of the time You can switch between languages using the WYSIWYG language tabs and you’ll never see the tags at all.

Occasionally, you might find one of the plugins you’ve got installed hasn’t got the language tabs set up on an editable field. If this happens you can simply enter your translation using language tags – they look like this: [:en]Welcome to Wales[:cy]Croeso i Gymru[:]. This is a quick handy work around, just pop in the language tags and [:fr]Voila![:]. When you’ve got a bit more time you can make your field translatable in the Advanced Settings.

Translating pages or posts.

With WPML you first create your post in one languange. When you’ve finished writing your post and saved it, the ‘plus’ icon in the Languages box shows you that you need to add a translation. Click this and it creates a new post. There are buttons to either ‘Copy content from [Welsh/English]’ or ‘Overwrite with Welsh Content’, handy if you’re translating directly in the editor window. When the translation is saved, and has been correctly linked with its sibling, you can click between the languange versions.

In qTranslateX both translations go into the same post. There are tabs within the edit window which allow you to click between the languanges. Click ‘Publish’ or ‘Update’ and this saves both languages. Simple.

Translating your theme and plugins

Most themes usually allow you to change the text pretty much everywhere, but there may be things like buttons or forms labels for instance, that are hard coded in the templates. When you test the website, you realise they’re not translated. This is where WPML’s string translation comes in. WPML > String Translation will list all strings and show if they’re translated or not. Use the search box to find your string and click translations to add your translation. (‘String’ is a term for a string of letters or numbers that are human readable i.e. a word, or a phrase, or a sentence).

qTranslateX does it a different way. Instead of the ‘String Translation’ tool, qTranslateX relies on the special language files that WordPress use for ‘WordPress in your language’. These files hold all a list of all the ‘strings’ with a translation for each string. These files are are MO (Mobile Object ) files and are made with the open source gettext language framework.

California Dreamin’ …
…The MOs & the POs (and don’t forget the POT)

In a nutshell, by using the gettext framework, WordPress provides language files for over 160 languages. Teams of volunteers contribute to the language files to make sure they’re up to date with the latest version. Plugin and theme developers are also encouraged to provide a language template (file extention .pot) and some language files (which have file extention .mo and .po). If your language isn’t there you can us the template to add your own language.

How does it work? And what’s POT, PO, MO?

1. POT – Portable Object Template:

The POT is made by the theme or plugin developer. It is simply a list of all the strings (messages, labels, phrases etc) used in the theme or plugin.

2. PO – Portable Object:

Using the POT the translator will create a PO for their language by adding suitable translations for each phrase. A theme often ships with a few PO files already translated for popular languages.

3. MO – Machine Object:

The PO is then compiled into a MO file that can be read by computers and is used by WordPress to display the website in the correct language.
The MOs and POs are provided with the plugin or theme in the language folder.

If you find an untranslated string it can be added to the MO file using tools such as POedit. For further reading check the WordPress website: [https://developer.wordpress.org/themes/functionality/localization/](https://developer.wordpress.org/themes/functionality/localization/)

Translating your menus

In WPML you need to create a separate menu for each languange. You use the menu translation and menu syncing features to set the languange, and link the translated menus together. Follow the instructions on their website carefully! The menu sync feature is a good idea, allowing you to compare the 2 menus and correct any discrepencies. But it can lead to unexpected results, again follow instructions carefully.

QTranslateX uses the language tab toggle within the menu editing screen. You have just one menu. Menu items are translated behind the scenes with the language tags within the menu items. For a while (round about the release of WordPress 4.5) this was buggy for large menus, but the team has fixed this.

Translating categories and tags
Don’t forget the milk [white, drink, calcium]

For content writers and editors this area seems to be a sticking point. They are used to choosing and adding new categories and tags from the post editor when adding a post or page. But translating the tags and categories often gets forgotten. This is probably because in both plugins you have to leave the post/page editor to translate categories, tags and other taxonomies. For both plugins you need to go to categories/tag editor. WPML also has a separate Taxonomy Translation screen to allow you to manage translation of all taxonomies in one place. Until a better way of doing this is released, it’s going to continue to be a training issue.

Translating slugs

Slug translation is integral to the way WPML works. Because of the way it creates a separate post for each language, it automatically creates a different slug for each language.

With qTranslateX the slug is the same for each language. While there’s a plugin you can install to translate the slug, I’ve not actually used it myself. I’ve never found a good enough reason use it. For each plugin you add to WP you increase the system bloat, making it increasingly difficult to keep software to date. Anyhow my feeling is if slug translation is important to your project, use WPML.

In summary/ In a nutshell/ round up

qTranslateX is free (although donations are welcome), so this might be a clincher for some people. It’s also a bit more hands on: customizations can be added through the functions file or directly in the templates. And the language tags can be used to add quick and dirty translations. For additional translations to theme and plugins you’d need to update your MO language file. For support you need to use the forums.

WPML is a pay-for plugin (cost $79 annually, $199 unlimited). It can be confusing and complicated to get new features set up. On the plus side, they have a great support team, where you’ll get an answer to your problem, if it hasn’t been answered in a previous thread. And there’s an interface to do most things you need to do.… Once you found out where…


While researching this blog I checked back to the grid on the WMPL website that compares WPML to alternative language plugins ( [https://wpml.org/home/comparing-wpml-free-paid-alternatives/](https://wpml.org/home/comparing-wpml-free-paid-alternatives/) ). The grid shows that while WPML does ‘everything’ on the list, qTranslateX only does ‘basic translation controls’. As you might guess, this is not the whole story. To be clear, for WPML to do some of the things in this list, you’d need to install an add-on plugin (e.g. string translation). Plus, some of the things (that this grid says qTranslate can’t do) are available in qTranslateX (e.g. menu translation) or can be done with a plugin (e.g. slug translation). However that aside, it’s qTranslateX ‘basic translation controls’ that make it so attractive!

Gettext: Images and Flash

Translating image replaced text

If you use CSS to replace your header text with a text based graphic remember these need translating too. By using gettext to change the lang attribute of the xhtml tag, you can then use CSS to change element background images. This gives added flexibility to wordpress plugins like polyglot and language switcher.

1. Prepare the graphics
You’ll need to prepare the graphic text for your chosen languages. Either in separate files or in one file if you are using Petr Stanicek’s (Pixy) Fast Rollovers Without Preload (note: if you create a separate graphic for each language and give it identical dimensions all you need to change in the css is the background image url.)
talk tab english version
talk tab welsh version

2. Prepare your CSS e.g.

html[lang="en"] #header h1{background-image: url(images/h.gif);}
html[lang="cy"] #header h1{background-image: url(images/h_cy.gif);}

3. Prepare your xhtml template
A well formed page should have a language attribute in the html because it helps screen readers speak more clearly and browsers to render characters correctly (more info: Language information and text direction ). It’s also a very useful formatting hook when designing multilingual sites!

<html lang="<?php _e('en') ?>">

4. update your .po file
add a message string to your .po file
#: wp-content/themes/test/header.php:42
msgid "en"
msgstr "cy"

When the user switches language the html lang attribute changes and your css pulls in the graphic with the correct language.

Changing file names using Gettext

Translating flash

You can also use gettext with the SWFObject method of embedding Flash files. Use the en string to change the file name of the alternative image and the flash file. When the language is English the image is image_en.jpg and the flash file is flash_en.swf. When the language is switched the gettext translates ‘en’ to ‘cy’ and the file names change accordingly to image_cy.jpg and flash_cy.swf.

Heres the example xhtml

<div id="flashcontent">

<img src="http://www.mydomain.com/images/image_<?php _e('en') ?>.jpg" width="654" height="150" alt="<?php _e('Alt text for my image') ?>" /></div>

<script type="text/javascript"> /* <![CDATA[ */ var so = new SWFObject("http://www. mydomain.com/flash/flash_<?php _e('en') ?>.swf", "myswfid", "654", "150", "6", "#0e0e70"); so.write("flashcontent"); /* ]]> */ </script>


A Bilingual blog

Making a blog bilingual is relatively straightforward. There are a variety of plugins available which allow you to provide your blog in two or more languages. Go to the wordpress translation and languages plugin page for more info.

They all use the gettext platform which is the GNU internationalization (i18n) library wikipedia.

A bit of gettext background

Gettext allows you to find all the natural language strings in a program by marking them up so they can be easily translated. (so string could become _e(‘string’) OR __(‘string’)). These strings are grabbed and put in a POT (portable object template), like a text file really.

Then translators come along turn the POT into a PO, and translate the strings so you end up with a French version; fr.po, a welsh version; cy.po, a British English version; en_GB.po etc. The POs are turned into MOs so they can be read by your program. And Voila! Bob’s yer Uncle you have a localised program in your language. More info on localizing wordpress

Before translation, documents have to be ‘gettexted’ as outlined above. WordPress has already gettextted its basic install. You need to make sure however, that your wordpress theme, pages and blog content have been gettexted too. Details of how you do that should be covered by the plugin documentation.

Polyglot and Language Switcher

Initially I chose Polyglot which worked really well in 2.0.5 after a few tweaks to the php files. However, after upgrading to 2.1.3 I tried to reactivate polyglot but certain sections of the site weren’t being translated.

In my original installation I’d changed some of the php functions to make sure everything could be translated. In WordPress 2.13 some of the php functions that I’d tweaked, had been changed in the upgrade. For instance the date functions are using all wp-locale, I couldn’t find where to ‘gettext’ the date. I’m sure its possible but I ran out of time.

Luckily, I found Language Switcher, a plugin that lives in a friendly hand-holding site called Poplar Software. Language Switcher, based on Polyglot, has been upgraded to work with WordPress 2.1.2 and above and has got really detailed yet easy to understand documentation. On uploading the software I found that all the “hackery” had been done for me and everything, even my illogical archive structure, was translated.