This blog post was initially commissioned to be part of a series exploring the different multilingual plugins for WordPress, for the popular French site WPChannel.com. As per my usual, I got a little carried away and ended up writing over 2000 words about my first experiences using WordPress as a multilingual platform, why I chose and stuck with WPML, and what the future may hold for multilingual WordPress. The French version was published yesterday (September 7, 2015) and can be found here. I’m pleased to publish the English version with you below, and thank Aurélien Denis for prompting me to share <3
—
My first big project using WordPress as a content management system (CMS) was in 2009, for the ECU Independent Film Festival of Paris. I had designed and built their existing site in standard HTML, picking up where my predecessor had left off using subfolders to manage four additional languages.
The move to a CMS would give the festival organizers, and their rotating team of volunteers, the reactivity and autonomy they needed to publish news and updates as submissions came in and selections were made, as well as for the post-festival wrap-ups. Although the festival itself ran in English, being based in Paris they felt obliged to have a French language version. And because it was a festival with international reach, they wanted to maintain as many additional languages as they could out of respect for the various participants.
I chose WordPress because I was more familiar and confident with it than others such as Drupal or Joomla, and feedback from colleagues assured me it was the way to go. The caveat: unlike other content management systems, WordPress didn’t (and still doesn’t) have multilingualism baked in. So, I went digging around for a plugin to address this need.
The basic needs of multilingual publishing
I was also still relatively new to multilingual publishing at the time. I had built a few multilingual sites before, with usually no more than two languages (French and English) and for the most part built in straight HTML/PHP with no content management component or database.
My primary concern in those cases was making sure the end-user could navigate fluidly from one page to the next, and from one language to the next. I was responsible for content integration, so the complexity of the question ended with a smooth navigation. There was only one source of content—my web pages—and those simply existed in multiple copies or sections of pages for each language.
I had also learned in working with clients that, although there is often a great ambition to publish all content in every proposed language, it’s easier said than done. There are more often than not holes where a page or post doesn’t exist in one or more languages, either because the translation wasn’t provided, or because the content wasn’t relevant in that language.
So at that point in time my understanding of the basic needs of multilingual publishing were:
- Front-end navigation between languages (a language switcher).
- Connectivity between language versions of content (a page or post) for fluid front-end navigation.
- Default behavior when content doesn’t exist in all languages.
- Back-end interface for translating or duplicating content, including taxonomies.
The more complex nature of multilingual publishing in WordPress
The very nature of a CMS creates a scenario where content is no longer coming from one source, but from multiple sources. It’s a platform composed of:
- The core code base.
- A theme for graphic interfacing and branding.
- Plugins to add functionality.
Each of these components in the site infrastructure contains text strings that must also be translated, and which the user may wish to modify. Add to that the need to manage user profiles, miscellaneous strings stored in database options (site title, site tagline) and additional user input sources like widgets, and suddenly there are a lot more things to think about.
Finally, and most importantly, there is the user. Not the end-user, the person visiting the site, but the user, my client, who wants autonomy over publishing and who isn’t equipped to deal with some of these more complex questions, and shouldn’t have to be. For the most part users don’t want to know how it works or why; they just want a fast and simple way to publish content.
My understanding grew to encompass the more advanced needs of multilingual publishing in WordPress:
- Support for string translation in themes.
- Support for string translation in plugins.
- Media translation, for translating image metadata.
- Support for translation of user metadata, strings stored in database options and in widgets.
- User-friendly graphic interfaces for translating extended content.
- Translation management/workflow for working with multiple translators.
At the time, there were even fewer plugins offering multilingual capability for WordPress than there are today. On someone’s recommendation, I ended up using ZDMultilang. I recall it being easy to install, but also very basic in terms of the functionality it offered. It was difficult to style into my front-end, and the navigation between language pages proved inconsistent.
Ultimately I couldn’t deliver what the client wanted with WordPress and ZDMultilang. As luck would have it, providing translations was also proving difficult for the client, so we ended up settling for a single language version.
Divide and conquer
Fast-forward to 2011 and the next project where I was confronted with the multilingual problematic. By this time, the first commercial version of WPML had been released. What immediately struck me was how they were approaching the complex problem of multilingualism by proposing several specialized plugins, instead of one single plugin to do it all. It was, and I maintain still is, a clever approach, which also showed that the folks behind it really understood my needs.
I installed it, set it up, and it just worked. The intuitive interface provided my client with a simple way to manage her content, toggling between French and English as needed, even in widgets. Documentation provided on the WPML website helped me style the language switcher to suit my needs. Yes, I had to pay for a license, but these costs are absorbed by the client and worth every penny to both of us. In fact, this might have been the first plugin to convince me overall what a great investment paid plugins can be!
Overview of the available plugins in the WPML suite
Multilingual CMS
The main translation component, which offers:
- Language choices
- URL structure
- Language switcher placement and style
- Options for redirection and browser recognition
- SEO options
- And the basic interface for translating pages and posts
Translation Management
This component has two primary functions: extended support for translating custom post types and taxonomies, and workflow tools for tracking translation status and working with multiple translators. Often required when working with other plugins such as WooCommerce
String Translation
Reads text strings prepared in gettext wrappers in themes and plugins and offers a graphic interface for translating those strings manually. Although WPML allows the simultaneous use of .po/.mo files, this module is also required when working with some plugins such as WooCommerce.
Media manager
This more recent component handles the translation of image metadata. It gives the user the choice of uploading a new image for a page or post translation, or using the same physical image that’s used in the source language, only giving it a new database entry so that the image’s title, alt tag, caption and description can be translated for each language.
Sticky Links
Purports to prevent internal links from breaking. I admittedly have never used this add-on.
There are also add-ons provided by WPML for working with third-party plugins such as WooCommerce and Gravity Forms, as well as an extension for testing the compatibility of themes.
There is no perfect solution, yet.
In general, when I find something that works for me, I don’t look any further. I have been using WPML successfully ever since, for projects of varying complexity and up to four languages. But none of the existing solutions is perfect.
Having worked with WPML for almost four years now on client sites, and as a WPML Contractor for a little over year, I’m well versed in the downsides to WPML, sources of frustration and causes for criticism for many.
Performance
Performance is one of WPML’s major drawbacks. It creates 16 additional tables in the WordPress database to manage its various components and store information. When a site accesses a translated page, extra queries (trips to the database) are needed to go in and access the content source, find the corresponding connector ID, then connect to the content for the requested language. For more complex pages, this can also mean translations for taxonomies, translated strings, third-party plugins, etc. That’s a lot of extra work that increases the time necessary to deliver the page to the browser.
Recent versions of WPML have made significant performance improvements. Using theming best practices, relying on .po/.mo files as much as possible instead of using the String Translation module and working with your host to provide adequate caching, or with a plugin like WP Rocket, can all help improve performance.
Things break
Put WordPress together with two, three or four WPML add-ons, a slew of additional plugins that may or may not need to interact with WPML and a theme that may or may not be coded according to WordPress best practices, and yes, it’s easy to see how things might break. And when people say, “it’s broken,” what they’re usually experiencing is something that doesn’t work as expected because there is some kind of conflict. Things aren’t necessarily broken so much as all these different parts aren’t playing nice together. And it’s easy to point fingers, because WPML is a complex piece of software, asked to accomplish a complex task.
Support
Which leads me to support. Support at WPML can be hit or miss, although again I would say it has greatly improved over the last year. The main issues I’ve experienced with support are long delays, as well as the number of exchanges it can take to actually make progress on resolving a problem. But the main difficulty is that things break (see above). And the source of these things can be very difficult to determine.
From my time working as a WPML Contractor, the number one reason things “broke” was due to sites running on premium themes not coded to WordPress standards. Even some themes that claim they are WPML compatible do a poor job on advising their customers on how to use them in conjunction with multilingual content, and an even poorer job of offering any support, sending the customer back to WPML to solve the problem. But of course, it is not WPML’s problem to solve.
Bugs
That’s not to say that there aren’t bugs. And again, it’s not so much things that are broken as conflicts that can occur, and take time to resolve. One recurring source of conflict has to do with page or category slugs that are the same in both languages. These are complex problems to fix.
“It doesn’t work, my content still only appears in one language.”
One of my favorite support requests during my time working as a contractor—favorite only because it made me giggle—were those people confused because WPML wasn’t magically translating their content for them. No, WPML does not translate content; it is simply a tool for managing the translation of content.
Though it is worth noting that the company behind WPML, OnTheGoSystems Inc., offers translation services under the name iCanLocalize that plug directly in to WPML. You do, of course, have to pay for them. Sometimes I wonder if it isn’t this parallel activity that creates the cause for confusion…
The future of multilingual WordPress
At WordCamp Europe in Seville this year, during his Q&A (38:50-43:05), Matt Mullenweg addressed the question of why multilingual capability isn’t an integral part of WordPress, by stating that there really wasn’t any data to reflect what percentage of the user base, high or low, found the feature to be a priority. “In the absence of [data], we keep the status quo of leaving things in plugins,” he said.
He did offer two suggestions to anyone passionate about bringing multilingualism to core:
- Introduce a feature plugin and build support in the community by holding regular meetings on the Making WordPress Slack. If something works well enough, the lead development team could consider it.
- Get data. He said that having data to support one way or the other whether multilingualism interests a significant enough part of the user base would go a long way to getting support (or validating that it isn’t a current priority).
Two days later, during Contributor Day, a small think tank gathered, lead by Simon Wheatley (Automattic, formerly of Code for the People) to discuss the multilingual question and what steps might be taken to introduce to core, if not full functionality, at least some key features that would help multilingual plugins do their jobs better.
Since then, we’ve been meeting regularly on the #core Slack to discuss three proposals:
- The introduction of a language post format element (lead by Simon Wheatley).
- A solution for the translation of text strings found outside gettext wrappers (namely database options, user meta and widgets, lead by Andrea Sciamanna).
- A solution for translating the registered names of taxonomies, currently something that most plugins struggle to do (lead by Marko Heijnen).
To follow this discussion, you can visit our p2, or follow the meetings on Slack Mondays at 18:00 CEST.