How translation changes interact with caches
Saving a translation can affect several independent cache layers. POM Translate invalidates the runtime entries it owns, but it cannot assume that a static page file or CDN edge copy has seen the change.
Identify the layer before purging
| Layer | What it can retain | Who refreshes it |
|---|---|---|
| POM Translate request cache | Source rows, translation maps, registered strings, exclusions, or slug lookups during one request | POM Translate |
| Persistent WordPress object cache | Supported POM Translate data and completed translated bodies across requests | POM Translate for its own keys; backend administration for broader flushes |
| POM Cache HTML | A complete anonymous page response | POM Cache purge and regeneration |
| POM Cache Progressive JSON | A supported progressive archive payload | Its dedicated invalidation or purge workflow |
| CDN or reverse proxy | Edge copies of HTML, JSON, redirects, or other responses | CDN/proxy policy |
| Browser | Its local response and assets | Browser cache policy or a fresh private session |
Clearing one layer does not prove that the others are current.
What POM Translate invalidates
When a stored target value changes, POM Translate clears its translation lookup for that row and locale. It also refreshes affected runtime output according to the source:
- post translation changes clear completed rendered-body entries for that post;
- supported metadata changes clear that post and locale’s translated-meta entry;
- menu-label changes clear the relevant menu cache;
- slug writes clear object-to-slug and slug-to-object lookups;
- registered-string changes refresh the registered-string map;
- custom URL changes clear the related runtime translation map.
Source extraction also invalidates the cached source rows for the affected subject.
These actions prevent POM Translate from knowingly reusing its own stale values after a successful save.
Full-page copies remain independent
A static HTML cache stores the complete result produced after WordPress and POM Translate rendered the page. If that file is served before WordPress starts, POM Translate cannot intercept the hit or replace one paragraph inside it.
After editing translated content, purge or invalidate every cached public URL whose complete output changed. That can include:
- the translated post itself;
- source and target archives that display its title or excerpt;
- menus or shared layout pages;
- taxonomy and search-like views;
- alternate locale variants;
- CDN entries in front of the origin.
Use the smallest safe scope. A global cache flush is not a substitute for understanding which pages consume the value.
Locale paths create different cache keys
/menu/, /fr/menu/, and /de/speisekarte/ are different public paths. A path-based HTML cache or CDN normally stores them independently.
Purging only the source route does not necessarily refresh a target route. Likewise, changing one translated slug can leave an old redirect or old-path cache entry alongside the new route.
A safe edit sequence
For a published translation:
- record the source and affected target URLs;
- save the target value or localized slug;
- confirm the administration interface shows the new value;
- invalidate the affected POM Cache HTML or Progressive JSON surfaces;
- invalidate matching CDN entries;
- request the origin target URL while signed out;
- confirm the new output and route;
- allow the normal cache layer to generate a fresh copy;
- request again through the CDN and verify the edge response.
When troubleshooting, bypass the CDN first and distinguish a WordPress render from a full-page hit.
Avoid destructive substitutes
Do not use Reset translation storage to clear a stale page. That action removes multilingual data rather than cache entries.
Do not flush the entire persistent object-cache backend as a routine first step. It affects other WordPress components and can create avoidable load. Start with the affected POM Translate, page, progressive, and edge scopes.
Verify invalidation
Change a unique target phrase on one staging post:
- warm the target route;
- save the changed translation;
- open the origin route without a page-cache hit;
- confirm POM Translate renders the new phrase;
- purge the page cache and warm it again;
- verify the stored page contains the new phrase;
- invalidate the CDN and request through the public hostname;
- confirm no layer still serves the previous phrase.
If the uncached WordPress response is correct but the public response is stale, the remaining problem belongs to a page, proxy, CDN, or browser layer rather than translation storage.