WPML 4.8.6 – The WordPress Multilingual Plugin + Add-ons

I reach for WPML when the site needs real language separation: different menus, different slugs, different SEO meta, translated product catalogs, and an admin workflow that doesn’t turn into a spreadsheet. Polylang is lighter, sure, but WPML is the one I see most often on serious WooCommerce installs because the ecosystem around it is wide.

The add-ons matter. Core WPML gets you the language framework; the pain relief comes from things like String Translation, Translation Management, Media Translation, and (for shops) WooCommerce Multilingual. If you skip those, you’ll end up “translating” half the site with custom fields and regret.

How it works internally (what WPML actually changes)

WPML isn’t a “pretty layer”. It’s a data model.

• It creates its own tables (you’ll spot wp_icl_* in the database) to map relationships between translations: this page in EN equals that page in DE, plus language metadata, translation status, and string packages.
• Each post still lives in standard wp_posts, but WPML filters queries to return the right language version. That’s why language issues often look like “my content disappeared” — it’s usually just filtered out by language context.
• Strings (theme texts, widget titles, plugin labels) get collected and stored via WPML String Translation. Those are not “posts”; they’re registered strings, and they can be cached aggressively.
• Language negotiation (how WPML decides language) is chosen in WPML settings:
  • directories (/de/),
  • domains (de.example.com),
  • parameters (?lang=de).
    Directories/domains behave best for SEO, but they also touch rewrite rules and caching more aggressively.
• WooCommerce Multilingual adds another layer: product translations, attribute/variation sync, currency/language switching logic, and translated endpoints. It’s powerful, but it increases query complexity — the shop is where you feel WPML’s weight first.

Where I make changes:

• language setup + URL format in WPML → Languages,
• translated slugs in WPML → Settings (and sometimes in SEO plugin settings too),
• string hunting in WPML → String Translation,
• field behavior (copy/translate) in WPML → Settings → Custom Fields Translation (critical for ACF/Elementor-heavy sites).

Where it usually breaks (and the fastest fixes I actually use)

1) 404s on translated pages / language directories Root cause: rewrite rules not aligned with chosen language URL mode, or stale permalinks after switching negotiation mode.

• Fix: Settings → Permalinks → Save (no changes needed) + clear cache/CDN.
• If you switched from ?lang= to /de/, I also re-check WPML → Languages and force-refresh caches.

2) “Wrong language” showing from cache (header switcher changes, page doesn’t) Root cause: page cache not varying by language cookie/URL, especially on setups with aggressive full-page caching.

• Fix: ensure cache varies by language URL (directories/domains are easiest).
  If you must use cookies, configure cache to vary by wp-wpml_current_language (depends on cache layer).
• Quick test: open the same URL in a private window and compare headers/HTML lang.

3) Translated layouts missing text (Elementor/ACF fields blank) Root cause: custom fields set to “Don’t translate” or “Copy once” when you need “Translate”.

• Fix: set field translation in WPML → Settings → Custom Fields Translation.
  For plugins that support it, add/adjust wpml-config.xml so fields are registered correctly.

4) Woo variations / attributes not matching across languages Root cause: attributes/taxonomies not synced, or products translated without proper “linked” attribute terms.

• Fix: in WooCommerce → WooCommerce Multilingual run the attribute/term sync tools; confirm attributes are set as translatable and terms exist per language.
• I verify on a single product first (one variable product), then bulk-sync.

Performance note (practical, not theoretical): on large sites WPML can add heavy joins. When TTFB spikes, I look for slow queries involving icl_translations joins and then:

• reduce “string scanning” behavior (don’t leave scanning running),
• limit admin listing filters,
• add object cache (Redis) so repeated translation lookups don’t hit MySQL every time.

Activation / updates (plain behavior)

I tested this bundle as installed, activated, and working (personally verified).

• Without a key: WPML usually still runs, but you lose official update channel, account sync, and support; some add-on downloads/registration flows won’t work normally.
• Updates manually: upload the new plugin zips via Plugins → Add New → Upload Plugin, or replace via FTP.
  If you’ve edited WPML files directly (I don’t), updates overwrite everything. Keep customizations in a small helper plugin using WPML hooks/filters instead.

You can find detailed instructions on how to update a theme or plugin on this page.

FAQs (real WPML pain points)