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.
Generated editorial image for this article showing a multilingual WordPress publishing workflow with connected pages, language nodes, menus, and review checkpoints.

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.

1

Use Polylang when you need a multilingual plugin; outside our own system, it is still our favourite WordPress multilingual plugin.

2

Use a proper workflow, not just translation: URLs, menus, internal links, hreflang, stale pages, QA, and editorial review are part of the job.

3

Use separate sites when isolation matters more than convenience.

4

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.