So you want a multilingual WordPress site? Good. Brave, even. 🌍
Let me save you a few years of pain, grey hairs, and emergency database work. Multilingual WordPress can be brilliant. It can also become a plugin-shaped trap if the language layer gets too much control over your content, URLs, menus, and SEO signals.
This is a warning from experience. WPML damaged this site. Polylang became our favourite general-purpose multilingual plugin. And now we have added our own AI-assisted language workflow on top of those lessons.
✨ 2026 update: our own AI-assisted language workflow
First: Polylang is still our favourite multilingual plugin outside our own system. That has not changed.
What has changed is that Devenia now has its own AI-assisted language workflow for publishing and maintaining this site across languages. Not โpaste text into a translator and hopeโ. An actual workflow.
What it helps with
- Language-specific URLs
- Translated page hierarchy
- Menu syncing
- Internal link repair
- Hreflang and metadata checks
What still needs humans
- Market fit
- Tone and terminology
- Commercial judgement
- Proof and examples
- Final editorial review
That is the important bit: multilingual work is not just translation. It is publishing architecture. Polylang gives a sane foundation. Our own system helps keep the wider workflow under control. 🧠
🎰 The multilingual plugin casino
WordPress does not speak multiple languages properly out of the box. Shocking, I know.
So you need a plan for content, URLs, menus, metadata, search signals, and editorial review. Most people start with โwhich plugin?โ That is understandable. It is also where the trouble starts.
✅ The good ones
- Polylang โ still our favourite general-purpose multilingual plugin outside our own workflow. Separate posts per language is a sane model.
- TranslatePress โ useful when a visual translation workflow matters more than strict editorial structure.
- qTranslate-XT โ lightweight in some setups, but think carefully about long-term maintenance.
💀 The disaster
- WPML โ the โindustry standardโ that damaged this site badly enough that we still treat it as a serious operational risk.
โBut everyone uses WPML!โ
Yes. And lots of popular technical decisions age badly. Popularity is not the same as operational safety.
🚨 WPML: the time it destroyed this site
This is not hypothetical. WPML damaged devenia.com. Database indexes disappeared, tables were damaged, and content was corrupted badly enough that recovery took specialist database work.
What happened
- Database indexes: gone.
- Database tables: damaged.
- Content: corrupted beyond normal repair.
- Years of work: partly lost permanently.
The recovery
We had to bring in a MySQL admin. He spent days piecing together what he could from the corrupted live database and backups.
The ugly part? Even the backup carried damage from the same failure. Some content came back. Some did not. 😤
So when I tell you to be careful with WPML, I am not being dramatic for sport. I am speaking from the experience of watching a multilingual layer damage the site it was supposed to help.
🏆 Why Polylang is still our favourite plugin option
After the WPML failure, we moved toward a simpler model: separate language versions as separate WordPress content objects, with clear relationships between them.
That is why Polylang still makes sense for many sites.
Why it works 👍
- Clean architecture: separate posts or pages per language are easier to inspect, repair, and reason about.
- Lower operational risk: fewer hidden translation layers means fewer surprises during debugging.
- Good editorial control: each language can have its own title, URL, copy, examples, proof, and CTA.
The trade-off 🤷
Polylang does not remove the work. You still need to keep menus, internal links, metadata, hreflang, stale pages, and localized copy under control.
That is where our own AI-assisted workflow helps. Polylang gives a sane foundation. The workflow keeps the publishing operation disciplined.
🔧 Alternative: run separate sites
For big, important, or legally sensitive multilingual projects, separate WordPress installations can still be the safer choice. More maintenance, yes. Less shared failure risk, also yes.
Advantages:
✅ Zero multilingual plugin dependency
✅ Independent optimization per market
✅ Lower single-point-of-failure risk
✅ Cleaner market-specific ownership
Trade-offs:
❌ More maintenance work
❌ More updates to manage
❌ Manual coordination between sites
❌ More discipline needed around hreflang and redirects
📋 SEO work you cannot skip
Whatever architecture you choose, do not mess up the boring SEO basics:
- Hreflang tags: search engines need to know which language and region each page serves.
- Localized keywords: search intent rarely translates one-to-one between markets.
- Localized proof: examples, objections, and trust signals should fit the market.
- Consistent URLs: choose a structure and avoid changing it casually later.
- Internal link repair: translated pages should link to translated pages where those pages exist.
- Editorial review: good multilingual publishing is not just grammar. It is whether a real buyer in that language would trust the page.
🎯 TL;DR
Skip WPML. It damaged this website badly enough that recovery required specialist database work, and some content was lost permanently.
Use Polylang when you need a multilingual plugin. Outside our own system, it is still our favourite WordPress multilingual plugin because the content model is easier to understand and maintain.
Use a proper workflow, not just translation. URLs, menus, internal links, hreflang, stale pages, QA, and editorial review are part of the job.
Use separate sites when isolation matters more than convenience. More maintenance, but less shared failure risk.
And yes, use AI carefully. Our own AI-assisted language system helps us move faster, but it works because it sits inside a controlled publishing workflow with human review. 🚀