We’ve had a wave of clients that operate all around the world. When clients have specific needs, such as multilingual content, then we need to investigate solutions to support them. Here I share my experiences as a developer with one, WPML. This review covers features from the Multilingual CMS Lifetime package and is intended for advanced developers.
[Update 1 January 12, 2016: The WPML team has implemented the feature to restrict editors to editing content in their own languages. This addresses one of my pain points with the plugin]
I want what’s best for clients and it’s frustrating when I can’t find a great solution for their problems. It doesn’t always make sense to custom develop every aspect of a client’s site when someone’s already done most of the work. Multilingual content in WordPress is a great example of where there’s already a complete solution, the plugin WPML. However, after working with it on a few sites my experiences have not been quite positive. I wanted to share some of the pain points I’ve experienced to help educate others when they are looking into multilingual sites.
My primary reaction to WPML after working with it on a few sites is that it lacks a primary audience. It seems that in trying to do too much and by taking care of every use case it ends up not doing anything particularly well. I tend to find this lack of scope and over complication in other complete package plugins, such as s2Member and WooCommerce. In all of these instances, WPML included, small quirks and caveats compound into a major frustration for both the developer and the client.
The first audience that a plugin like WPML is built for is for the owner of a traditional WordPress blog. This type of user only operates WordPress as a blog and may have a couple of pages. All they care about is being able to create posts in different languages and have the user select their language. Here is where WPML is the most painless.
Installing it allows the owner to set up their languages and provides end users with a language selecting widget. However, if the site owner wants to do anything more advanced, like have multiple users translating content, or using a language that’s not in the default list, the lack of audience for WPML quickly rears its ugly head. WPML suffers from what I call “option-itis”.
I define option-itis as when a plugin presents too many configurable options to a user. There are screens on screens of options in WPML. Instead of coming up with specific use cases and configuration profiles, WPML instead lets the user tweak many little things, often without clearly presenting what a setting does, or more importantly, why it should be set in that way. Many monolithic plugins suffer from option-itis, and WPML is not spared from this condition.
Option-itis will be front and center to the next form of WordPress user: the user who runs a CMS focused site. This user knows a lot about WordPress and uses many of its capabilities. When a developer talks about how they made a custom post type and taxonomy, they know where to go to add content. When they mention custom fields, the CMS user knows they will be editing ACF enhanced content. To the CMS user, WPML adds many, many screens with too many checkboxes and radio buttons to count.
Questions like “What’s the difference between translating and duplicating content?” “Why do I need to select a translation service to add a translator?” and even “Why should I use a translation queue when my authors write their own translated content?” remain constant. I’ve worked with the plugin for a few months and am not sure what half of the buttons do and what they imply for things moving forward if I enable them.
On that note, you may be thinking, “A developer could hide the extra screens that this plugin produces for CMS site builders!” This is true, however, that typically isn’t in the budget, and finding out that information is not always the easiest.
If WPML is too advanced for the blog user or the CMS user, then certainly its target audience must be the WordPress-focused developer? From personal experience, this is simply not the case. First, there’s a lack of a stable public facing API. Things like getting a list of languages, getting all of the translations for a piece of content and linking to your region or language specific landing page, all require the developer to wrap verbose filter calls with their own functions. The second issue is a lack of documentation. The little documentation WPML has is hard to find, use and is often out of date. Third, is that the plugin is filled to the brim with bugs. All of these pain points, combined with options-itis, will result in frustration for both the developer and the client.
To elaborate on the last point; I encountered many, many bugs when trying to use the plugin. I’d give tutorials to the client, only to find their actions produced bugged behavior. I submitted multiple bug reports during my time with the plugin. The issue reporting itself leaves something to be desired and it is very hard to find out if your issue has been reported before or if an issue has been fixed. I had to give almost daily reports on the bugs I submitted and encountered to the client to keep them in the loop as to when they would get fixed. That being said, I give OnTheGoSystems, Inc. credit for their fast and friendly support (Webspec has a developer license, which offers us lifetime support). When bugs were reported they were quickly triaged and often were quickly fixed (in a beta version). So, while you will no doubt encounter many bugs when using WPML, you can be assured that if you report them, they will get taken care of. OnTheGoSystems has also recognized that they introduce a lot of bugs and regressions and has started an initiative to cover more of their codebase with automated testing.
So far my frustrations have been at the high level. There are some cautionary tales that I’d like to warn future developers of.
The first is of having a site with multiple regions. WPML is designed to have content in languages, not regions. For example, your site may have a page about one of your products. WPML then wants you to translate that product page into other languages such as German and Spanish. By default, it expects your product to exist across all languages and have relatively the same content. What happens though, if your company offers different products depending on the language or region? A site I recently developed offered different products and services depending on the country, featuring over 10 regions and over 20 languages between them. WPML expected that the Spanish version of the site had the same products, regardless if the user was from Latin America or Spain, and didn’t handle this particular use case well. While the issue can be overcome, I recommend instead using a taxonomy or even a multisite to change the content based on the region and then use WPML for the translations. This will save you a lot of headache, declutter your admin and even speed the site up.
[Update 1: The WPML team has implemented this feature through the Access plugin.] The second use case is the idea of editors only being able to edit content that they are assigned to. My client needed to set up users that could only edit content that they are assigned to but retain their ability to view the other site content. Simple, right? Set them up as an editor, add their language pairs through WPML and now they can’t click translate on content that’s not in their language. This works, but translating content is not the same as creating it. The users can still edit, create, and delete content even though they are not assigned that language — not the ideal situation. As an example of the poor, outdated documentation that WPML offers, a quick Google search will link you to old articles of attempts to implement this that were never finished. I asked support if this was possible and presented many links that showed this feature was planned but not implemented and they confirmed this use case is not possible.
The last case I want to talk about is the plugin’s string translation feature. WPML handily provides an interface to WordPress’ gettext implementation, meaning that clients can, through the interface, provide translation to our custom developed theme and plugin strings. This is great, and was very handy during development. However, training a client on how to do this is a very long and confusing process, and to top it all off, I encountered multiple bugs during the process. The string scanner seemed to ignore some of my strings, and even corrupted the data (luckily on a test site). Some theme strings were untranslatable without upgrading to a beta version of the plugin.
WPML, like all monolithic WordPress plugins comes with its own quirks and caveats. If the client only needs an out-of-the-box solution, then this plugin will work. However, the more advanced the requirements, the more those quirks and caveats start to combine into a major, frustrating problem for both the developer and client.
