Page caching on a translated WordPress website

Why there is nothing to configure

Because the language is in the URL, a page cache sees two URLs where you see two languages. No Vary header, no cookie-aware caching, no cache-key rules. A CDN in front of it behaves the same way.

This is the practical payoff of the URL decision, and it is why WPGlotty needs no cache integration to be correct: only to be quick.

Clearing after a change

The moment a cache is stale is when a translation changes: that one URL now has cached HTML with the old text in it. WPGlotty clears it automatically for the caches it recognises.

• WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache
• Cache Enabler, Nginx Helper, SiteGround, WP Fastest Cache
• Breeze, Hummingbird, Kinsta, WP Engine, the official Cloudflare plugin

A cache it does not know

If none of those is present, WPGlotty says so once: it saved the translation but could not clear anything, so clear it yourself. The notice returns the next time it happens rather than nagging on every screen.

Server-level caches (nginx FastCGI, Varnish, a host panel) usually have no PHP function to call. Two filters let you plug one in.

add_filter( 'bdt_purge_all_handled', function () {
    my_host_purge_everything();
    return true; // tells WPGlotty it was handled
} );

add_filter( 'bdt_purge_url_handled', function ( $handled, $url ) {
    my_host_purge( $url );
    return true;
}, 10, 2 );