This is an ongoing series about Webspec’s experience with WPML. It’s intended for developers who are researching into it and know advanced WordPress development. Read Part 1 of Nick’s blog here.
Introduction to Insta-Pro
Insta-Pro International® produces machines that turn raw ingredients, such as soy, into usable products, such as animal feed and food ingredients. What sets them apart from their competition is their machines use a chemical free process. Insta-Pro operates in over 100 countries across all continents except Antarctica. Their previous site relied on Google Translate to provide translations. When they approached Webspec for a new website in January 2015, the ability to have tailored translated content was one of their primary needs. They also put in major effort to maintain their blog, with over 200 posts since 2012. The multilingual solution they required would need to allow for them to bulk export the blog posts, both past and future, that they wanted translated.
Qualifying the Use of WPML
Unlike the site discussed in the previous post, Insta-Pro lent itself to WPML’s way of doing things. While many of the same problems that I discussed before persist: namely option-itis, lack of an API, and it being hard to train others, the multilingual process itself went a lot more smoothly. One reason is the experience and knowledge of the caveats gained from working with the plugin previously. The other two reasons for a smoother implementation have to do with the site’s content structure.
Insta-Pro has the same content across all languages. They have the same static pages, blog posts, products, services, and staff. Pages and content are translations of each other, not unique to each language, country, or region. This is how WPML expects the site to function. The site in the previous post had different content for different languages, something a taxonomy would be better suited for.
Insta-Pro also has specific languages, not countries. In the site from the last article, Spain Spanish needed to have different content than Colombian Spanish as the product lines were different for the two countries. With Insta-Pro all Spanish content is appropriate for all Spanish speakers, regardless of the country in which they reside.
Having the same content in languages as opposed to countries meant that WPML’s frontend features worked almost out of the box with little intervention on my part.
Insta-Pro’s Specific Workflow
XLIFF Export
Insta-Pro makes use of the ability to export content to XLIFF files so they can be sent to a local translation service. The actual process of exporting and importing the files is pretty painless, getting to the right screens, preparing your content, and training the client to do so, however, are not simple tasks.
To go along with option-itis, WPML introduces another disease, one I call Click-the-right-buttons-disease, or CRBD (“curbed”). What I mean by “clicking the right buttons” is that in order to get the intended result the user has to click the exact set of buttons in the exact, specific order, or else they won’t get the desired result from this process. There are many places where they think they are done, but actually have to click some buttons on a different screen to continue. If an end user wants to send a single blog post to a local translator through XLIFF they must:
- Find the content on the translation dashboard, a brand new interface that isn’t built into WordPress.
- Add the content to the translation basket, making sure “translate” is selected for all languages.
- Add the content to the translation basket.
- Locate and go to the translation basket, another brand new interface not seen anywhere else.
- Send the items to translation, making sure to select the correct user as the translator or else they lock themselves out of the translation process.
- Find the translations queue, yet another brand new interface not seen anywhere else.
- Find the piece of content they want to export, and locate the export buttons.
If at any point in time a step is forgotten or a screen can’t be found, the end user is out of luck. CRBD has reared its ugly head.
The amount of steps, new interfaces, and paradigms that an end user must learn is an involved task; a single training session will not be enough to get the hang of the process. The client shouldn’t have to call the developer every time they want to add a blog post. That sounds like a problem a CMS could solve, Webspec recommends WordPress… wait.
On the note of training, there’s an additional problem I ran into, something that I will take credit for and will learn from: I trained the client on how to use the translation management feature using my admin account. Instead of creating a user with the same role and permissions as the client, I foolishly showed the steps the admin would take. I then came to find out that by default, the editor role doesn’t have the required permissions or is able to see the same screens that the admin does. Demonstrating with a user with the same roles is something that in hindsight makes sense, but wasn’t clear to me at the time.
However, my training mistake doesn’t give WPML slack on how it expects end users will be translating the site. WPML is focused on and assumes that there will be one admin account marking content as translatable and exporting using XLIFF. It is not built with having multiple editors in charge of what gets translated in mind. I ran into the problem where, by default, editors can’t even access the areas to mark content as translatable.
This leads to problems touched upon on the first article. There’s a capability that can be granted to roles that allows them to manage translations. However, all of the articles about it are outdated or incorrect, and there’s no documentation. Through browsing WPML’s code I was able to find the specific capability and give it to the editor role (if you stumble across this article in a search, it’s the “wpml_manage_translation_management” capability). Like in the previous article, it makes me wonder who the target audience for WPML is, because it’s certainly not for developers.
Flexible Content / Repeaters
Webspec makes liberal use of the Advanced Custom Fields plugin in our projects. ACF has a pretty good integration with WPML, but adds wrinkles to the XLIFF export process. ACF creates two different meta entries per field, one containing the actual data (for example, one named price), and another that contains a field id (_price). The link to the field starts with an underscore, which makes them easier to identify and turn off. These link fields will need to be turned off as XLIFF file translations are often billed on a per word basis. This extra data will have a tangible cost as they increase the word count.
When using a repeater or flexible content field, however, the names of the fields and the data stored goes beyond a field name starting with an underscore. Each row on a repeater or flexible content field adds extra meta to the content that tracks information about its row. They’re saved with names such as “content_section_3_images_0_image,” and on a site with a few pages with repeaters there could be hundreds of these fields. Turning on or off certain fields for export only makes sense with a set amount of fields. To tell a client that before they can export a page they have to hunt for the fields they want to turn on or off is out of the question. Based on that caveat, flexible content and repeaters should not be used when it is known that the content will be exported through XLIFF.
A good side, though, is that a known amount of static fields are less of a hassle to implement. They can be turned on or off by a developer once at the start of development and don’t have to be worried about again. The presence of flexible content and repeaters also does not affect content types that don’t have those fields attached. That means with careful planning they can still be used in key areas across the site.
Final Thoughts
Each site is going to be different in their multilingual requirements and setup. There’s no hard or fast rule to determine if WPML is the right decision. But after each use Webspec will gain more knowledge of its pros, cons, and gotchas to help make a better decision for clients when it comes to integrating multilingual capabilities.
