Devenia multilingual WordPress guide
Multilingual challenges
Multilingual WordPress is not just translation. WPML damaged this site, Polylang is still our favourite plugin option, and Devenia now uses its own AI-assisted language workflow to control URLs, menus, links, hreflang, QA, and review.
Multilingual WordPress is publishing architecture
So you want a multilingual WordPress site? Good. Brave, even.
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.
Reader decision
- Which parts of the language workflow need plugin support?
- Which parts need editorial control, QA, and human judgment?
- How much operational risk can the site tolerate if the language layer fails?
What changed in our 2026 workflow
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.
Polylang as foundation
Polylang is still our favourite multilingual plugin outside our own system because separate posts per language are easier to inspect, repair, and reason about.
AI-assisted workflow
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.
Humans still decide
Market fit, tone and terminology, commercial judgement, proof and examples, and final editorial review still need humans.
WPML: the time it damaged 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.
We had to bring in a MySQL admin. He spent days piecing together what he could from the corrupted live database and backups. Even the backup carried damage from the same failure. Some content came back. Some did not.
What happened
- Database indexes: gone.
- Database tables: damaged.
- Content: corrupted beyond normal repair.
- Years of work: partly lost permanently.
- The language layer damaged the site it was supposed to help.
Choose the multilingual architecture deliberately
WordPress does not speak multiple languages properly out of the box, 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.
- Good plugin options: Polylang is still our favourite general-purpose multilingual plugin outside our own workflow. TranslatePress can be useful when a visual translation workflow matters more than strict editorial structure. qTranslate-XT can be lightweight in some setups, but long-term maintenance needs care.
- The operational risk: WPML is popular, but popularity is not the same as operational safety. Lots of popular technical decisions age badly.
- The separate-site option: For big, important, or legally sensitive multilingual projects, separate WordPress installations can still be the safer choice.
- Why Polylang works: Clean architecture, lower operational risk, and good editorial control: each language can have its own title, URL, copy, examples, proof, and CTA.
- What Polylang does not remove: You still need to keep menus, internal links, metadata, hreflang, stale pages, and localized copy under control.
Multilingual work is not just translation. It is publishing architecture. Polylang gives a sane foundation, and a controlled workflow keeps the wider publishing operation disciplined.
SEO work you cannot skip
Whatever architecture you choose, do not mess up the boring SEO basics.
Language and URL signals
- 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.
- Consistent URLs: choose a structure and avoid changing it casually later.
Trust and review signals
- Localized proof: examples, objections, and trust signals should fit the market.
- 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.
Separate sites: safer when isolation matters
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.
- Advantage: zero multilingual plugin dependency.
- Advantage: independent optimization per market.
- Advantage: lower single-point-of-failure risk and cleaner market-specific ownership.
- Trade-off: more maintenance work and more updates to manage.
- Trade-off: manual coordination between sites and more discipline around hreflang and redirects.
- Separate sites are not automatically simpler. They are safer when isolation matters more than convenience.
The architecture decision should match the commercial, legal, editorial, and operational risk of the multilingual project.
Frequently asked questions
Is multilingual WordPress just translation?
No. Multilingual work is publishing architecture: URLs, menus, internal links, hreflang, stale pages, QA, localized copy, and editorial review are part of the job.
Why does Devenia still prefer Polylang outside its own workflow?
Polylang keeps separate posts or pages per language, which makes the content model easier to inspect, repair, reason about, and control editorially.
Can AI replace human multilingual review?
No. AI can help inside a controlled workflow, but market fit, tone, terminology, commercial judgement, proof, examples, and final editorial review still need humans.
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.
- 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.
- Use AI carefully inside a controlled publishing workflow with human review.
A multilingual WordPress system should make every language easier to inspect, repair, review, and trust.