WPML Doesn't Work With My Shop
Nobody's Bug
“WPML doesn't work with my shop.”
For a couple of years, that was one of the most common tickets we received. It was also one of the least useful.
It didn't tell us what the customer had tried, which shop plugin they were using, or what “doesn't work” actually meant. Maybe the products didn't translate. Maybe the prices translated but the checkout didn't. Maybe everything looked fine until an order came through in the wrong language.
Looking back, I think those tickets were some of the most valuable information WPML received during those years. They just didn't look like it at first.
Every WordPress site is a stack of software built by people who often have never spoken to each other. A theme from one company, a shop plugin from another, a translation plugin from a third, and maybe a page builder on top of all of it.
The customer sees one website.
When something breaks, they usually contact whoever they think should be able to help.
The tricky part is that the problem is often not really in any one product. It sits somewhere between two of them. Each product might be working exactly as its developer intended, but together they produce something that doesn't work for the customer.
That space between products doesn't really belong to anyone.
So, in practice, it belongs to whoever decides to take responsibility for it.
From complaint to requirement
From 2013 to 2018, I led the compatibility program at WPML. The basic job was to make sure WPML worked with the themes and plugins people were actually using.
The program eventually covered hundreds of integrations. I personally handled many of the most important ones. Those were particularly important because when one of the most popular integrations broke, we felt it very quickly.
One of the first things we learned was that a vague support ticket isn't really a requirement.
“Doesn't work with my shop” had to become something we could actually test.
A product page should have a translated version. That version should show the right price and currency. The customer's language should stay consistent through the cart and checkout. The order email should arrive in the language they used when shopping.
Now we had something concrete.
We could test it, give it to a developer, and explain to a third-party author exactly what wasn't working. Before that, all we really had was a frustrated customer saying that something was broken.
A lot of the compatibility work was this translation, repeated over and over: taking a customer's description of a problem and turning it into something that two separate development teams could actually work on.
The other part was working with those teams.
The people building the themes and plugins didn't work for us. They had their own products, priorities and roadmaps, and there was no reason they should automatically put our problem at the top of their list.
What usually helped was arriving with evidence rather than a vague request.
Here is the site. Here is the exact interaction that fails. Here is what we think needs to change on your side, and here is what we'll change on ours.
That made the conversations much easier, and it meant the engineers on both sides could spend their time working on the actual problem.
WooCommerce Multilingual came out of this kind of work. We kept seeing the same problems around WooCommerce and WPML, and eventually it made more sense to build something specifically for that space between the two products rather than keep fixing individual cases.
Taking responsibility for the outcome
There are two things from those years that I still think about.
First, the customer doesn't really care whose bug it is. And honestly, they shouldn't have to.
If someone's checkout is broken and you tell them it's because of a third-party theme, you might be completely correct. But their checkout is still broken.
Sometimes the quickest way to solve the problem was to fix something on our side, even when the root cause wasn't technically ours. The customer didn't need a lesson in who was responsible. They needed their site to work.
Second, you can't really own an outcome that you don't measure.
We published a client-facing newsletter about our compatibility work every week for years. There was a marketing side to that, of course, but it also created a useful bit of pressure internally. Every week, we needed to have something real to talk about. And customers could see what we were actually doing.
The program started with two people and gradually grew into a larger team. I recruited people from inside WPML support, partly because they already knew the problems. They had spent years reading tickets about things that “didn't work,” so they had a pretty good idea where the gaps were.
Where AI fits
AI can help with part of this today.
Give an AI agent a support ticket, a list of installed plugins and some debug information, and it can often turn a vague complaint into a reasonable list of things to investigate. That's useful, and I'd absolutely use it.
But there's a part AI can't really solve for you.
It can't decide who should take responsibility for the space between two products.
That's still a human decision.
An AI system can tell you that the checkout is failing because two plugins aren't handling the same piece of information correctly. Someone still has to decide to contact the other developer, work out what needs to change, and make sure the customer gets a working site.
If you build a product that depends on other people's products, I think that's part of the job.
Find the gaps. Work out what needs to be true on both sides. And, where it makes sense, take responsibility for the outcome even when the code isn't entirely yours.
Those vague support tickets are often where those gaps are hiding.
It's worth reading them a little more carefully.