A multilingual WordPress store sounds like one plugin and a week of work - that is the most expensive illusion in this whole subject. The owner sees a screenshot with flags in the menu on the vendor’s site, adds the cost of translating the products, and plans to be selling in Germany a month from now. Then it turns out the products really are in German, but the order confirmation email arrives in Polish, the checkout still asks for a Polish tax number, and the terms of sale are a file nobody ever touched.
A second language in a store is not a translation layer laid over the top. It is a second version of the entire buying path: the product page, the cart, payment, shipping, the email after the purchase and the returns form. The plugin handles the smaller part of that job. The rest is decisions no wizard will make for you.
In this post I go through the four things clients entering a second market actually ask me about: which plugin to pick for a store rather than a blog, what genuinely has to be translated, how to handle currencies, tax and shipping abroad, and what it costs - not to build, but to keep running. At the end I say plainly when I would not add a second language at all.
WPML, Polylang or Weglot - and why a store is not a blog
There are four tools I regularly see at clients, and they fall into two families.
WPML and Polylang keep translations in the WordPress database. Every product in German is a separate entry linked to the Polish original. The upside: anything that reads the database can see those products - a CSV export, an ERP integration, a courier plugin, a shopping feed. The downside: the database grows, and every product has to be deliberately created in the second language. With WooCommerce both need a store add-on (WPML has WooCommerce Multilingual, Polylang has a separate paid Woo edition), and without it translation stops at content and falls apart at the cart.
TranslatePress and Weglot work the other way round: they intercept what the page has rendered and swap the text. Setup is fast because you are not duplicating entries, and you can translate by clicking around the live site. Weglot also stores the translations on its own side, on a subscription billed by word count. The drawback for a store is concrete: the content is not in the database, so integrations and exports still only see the original language, and if you stop paying, the second language disappears with the subscription.
That is where my rule comes from, and where the title of this section comes from too. A blog has text and images, so overwriting the rendered layer is enough. A store has attributes, variants, prices, order statuses and documents - that is data, not just copy. If the catalogue is large or the store leans on integrations, I pick the family that keeps translations in the database. If there are a few dozen products and the second language is meant to be a cheap market test, an overlay tool is an honest choice.
On “WPML or Polylang” the gap is smaller than the forums suggest. WPML is more mature around WooCommerce and has better tooling for managing a translation queue. Polylang tends to be lighter and cleaner in the admin. Both need watching during updates, because both reach deep into the store.
What helps: before you choose a plugin, answer one operational question - who inside the company is going to write the German description for product number three hundred, and when. If there is no answer, the plugin choice is the smallest of your problems.
What actually has to be translated - checkout, emails, attributes, documents
This is where implementations fall apart. The list is longer than it looks from the admin panel:
- Products and categories - names, descriptions, short descriptions, and the URLs (slugs) of both.
- Attributes and their values - translating the “Colour” label is not enough. “Red” and “Navy” are separate entries too, and without them your filters show the customer Polish words.
- Variants - a variable product has its own combination names, and they love to stay in the original language inside the cart.
- Transactional emails - order confirmation, status change, shipping, refund, password reset. The customer gets these at the tensest moment of the purchase, and they are usually the last thing anyone checks.
- Checkout and validation messages - field labels, error text, payment and delivery method names, the consent copy under the buy button.
- Strings from the theme and plugins - “Add to cart”, “Out of stock”, the labels from your courier and invoicing plugins. These are translated as strings, with a different tool than the one you use for content.
- Documents - terms of sale, privacy policy, returns and complaints, the cookie notice. This is not a copy-paste from a translator, because these deal with consumer rights in a specific country. I write this as a web practitioner, not a lawyer - have the wording confirmed by a lawyer who works in that market.
One practical trick for a large catalogue: do not translate products one by one in the admin. Export them to a file, translate in a spreadsheet or a translation tool, and import them back - exactly the way I describe in the post on importing and exporting products in WooCommerce. Hours of clicking turn into a single import run.
What helps: place a test order in the second language, with real money, on a phone. Follow it all the way to the confirmation email and the invoice. A sentence in the wrong language will surface somewhere you did not expect.
Currencies, VAT OSS, shipping and payments for the second market
Language is half the job. The other half is money and logistics, and no translation plugin handles that on its own.
Currencies. A store set up to sell abroad needs either a second currency or a deliberate decision to stay on one. Converting on a live exchange rate looks convenient, but it produces prices with odd fractions that read as accidental in the other country. I prefer prices set manually in euro, rounded the way the local competition rounds them. Then the price is a commercial decision rather than the output of a rate table.
Tax. Selling to consumers elsewhere in the EU above the EU-wide distance selling threshold means charging VAT at the destination country’s rate, under the OSS scheme. On the store side that means tax rates per country and paying attention to whether your prices are gross or net in each of them. This is not tax advice - agree the rate configuration and the OSS registration itself with your accountant; my job is to make the store calculate exactly what they tell you it should.
Shipping. A second country is a separate zone, separate free shipping thresholds and different carriers, because the local one is often cheaper and better trusted there. The mechanics are the same as for a domestic store, and I covered them in the post on shipping zones and free shipping thresholds - only the numbers and the carriers change. Add a return address in that country, or a clear statement that returns travel back to Poland, because that genuinely affects the decision to buy.
Payments. A Polish instant-payment method means nothing in Germany. There, instant bank transfer, buy-now-pay-later and cards are what matter; in the Netherlands you simply do not sell without iDEAL. Payment methods are chosen for the market, not out of habit from the home one.
If that list looks like more than a weekend of work, you are reading it correctly. That is what an honest entry into a second market costs, and it is why in my WooCommerce store builds I treat a second language as its own project stage rather than a setting.
One thing I am deliberately not unpacking here is hreflang and the SEO of language versions: the URL structure, the tags that tell a search engine which version belongs to whom, and avoiding a situation where two versions compete for the same query. That deserves its own post; the groundwork for store visibility is in my piece on SEO for online stores.
What it costs to build and to keep running, and what I do differently
The build cost has four parts, and only one of them is visible up front.
The first is licences. A multilingual plugin for a store is usually an annual licence, on a higher tier than the blog edition, plus often a second licence for the currency module. It renews every year, and skipping the renewal means missing updates - with a plugin sitting inside the cart, that is not a risk I would take. Check current pricing on the vendor’s site on the day you buy, because the tiers change. For how these annual fees add up across a store’s budget, see my post on the real cost of WooCommerce plugins.
The second is translating the content. Machine translation with a human edit is a sensible compromise for product descriptions. For sales pages, documents and transactional emails I bring in a translator, because those either read as credible or read as spam.
The third is the implementation work - configuration, rewiring attributes, theme strings, tax rates, shipping zones, and test purchases in both languages.
The fourth, and the one most often missed, is upkeep. From launch day, every new product is two entries instead of one. Every promotion is two descriptions. Every change to the terms is two versions. Every larger WooCommerce update can knock the strings out of alignment and they have to be reviewed. On top of that comes customer service in the second language, because sooner or later someone replies in German. That is not a one-off cost, it is a permanent overhead on the whole operation.
What I do differently from most of the implementations I end up repairing: I start from the list of things that need translating and from the question of who will maintain them, and only then pick the plugin to fit that answer. I do not translate the blog at the start, only the buying path, because that is what sells. And I launch the second language on a narrow slice of the catalogue rather than all of it - if the market answers, I expand.
What helps: work out the upkeep before you work out the build. If maintaining a second language does not fit into your month, the build was the cheapest part of the problem.
When a second language is not worth it
I will say this plainly, because few people do: in a fair share of the stores I look at, I would not add a second language.
I would not add one when there is no signal of demand from that market at all - no enquiries, no traffic, no orders already trickling in despite the site being in Polish. Multilingual does not create demand, it serves demand that exists. I would not add one when there is nobody to answer emails in that language either, because the first complaint exposes that within a day. And I would not add one when the margin cannot absorb the cost of shipping and returns abroad, because then every successful order becomes a problem.
There is usually a cheaper test within reach. One well-written page in English with an enquiry form shows whether anyone is asking, at a fraction of the cost of full multilingual. Selling through a local marketplace validates demand without touching the store at all. Only once orders start arriving does building a second version of the store stop being a bet and start being a response to something that already exists.
There is also the question of which language. English is convenient because it covers several markets at once, but in Germany, France and the Czech Republic it converts noticeably worse than the local language. One properly done local language usually beats three done halfway.
Summary
A multilingual store on WordPress is not a plugin, it is a second version of the entire buying path: products, attributes, checkout, emails, documents, currencies, tax and shipping. With a large catalogue and integrations I pick the tools that keep translations in the database, meaning WPML or Polylang with the store add-on; with a small catalogue and a market test, an overlay like Weglot or TranslatePress is an honest shortcut. The biggest cost is not the licence or the build, it is maintaining two versions of every piece of content for years afterwards.
If you are weighing up a second language and are not sure whether your store is ready for one, send me the address and the market you are aiming at. I will go through the store, tell you which parts need translating and which need rebuilding, and whether in your case a second language is the right move or a premature one.
Frequently asked questions
WPML or Polylang for a WooCommerce store? Both keep translations in the database and both need a WooCommerce add-on. WPML is more mature around the store side and more comfortable with a large number of products; Polylang tends to be lighter and simpler in the admin. With a catalogue in the hundreds and ERP integrations I go with WPML; for a small store Polylang is entirely enough.
Can I translate the store with machine translation? Product descriptions, yes, as long as someone reads them after the machine. Transactional emails, checkout, sales pages and legal documents I leave to a human, because those are the texts a customer uses to judge whether the store is serious. Raw machine output in the terms of sale shows from the first sentence.
Do I need a separate domain for the second country? Usually not. A subdirectory on the same domain is the simplest to maintain and benefits from whatever the domain has already earned. A separate country domain makes sense when you are building a distinct brand there, or when local trust demands it, but it means starting SEO from zero.
How long does adding a second language take? It is measured in weeks rather than days, and what decides it is the size of the catalogue and the number of plugins hooked into the cart. Switching the plugin on is a matter of hours. Translating the catalogue, the theme strings, the emails and the documents, then testing a purchase in both languages, is the bulk of the work and it sets the date.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.