Every change you make lands on a different schedule, and that is the usual reason a change looks like it did not work. This page is the whole picture in one table, so you can tell "not applied yet" from "applied, and something is serving you an old copy".
The table
| What you changed | What happens | When a visitor sees it |
|---|---|---|
| Edited a translation by hand | Your text replaces the machine translation, and the string is marked Verified | Next page load |
| Retranslate with AI on a string | A fresh machine translation replaces what was there | Next page load |
| Deleted a translation | The string is translated again from scratch | Next request for that page |
| Added a glossary rule matching a whole string | Applied ahead of anything stored or cached | Next page load, nothing to clear |
| Added a glossary rule matching a term inside a sentence | The stored translation for that sentence is unchanged | Only when that sentence next needs a fresh translation |
| Deleted a glossary rule | The previously stored wording is served again | Next request, and cached pages can lag up to 24 hours |
| Added a language | Nothing is translated yet | The first time each page is requested in that language |
| Disabled a language | It disappears from the switcher and its URLs stop serving | Immediately |
| Removed a language | Its words come off your counts, translations stay stored | Immediately |
| Changed Translation Rules (selectors, excluded pages) | Saved at once, but pages already translated keep what they have | After the cache is cleared |
| Clear translator cache | The translator fetches translations again instead of serving its own copy | Next page load, for the whole project |
| Ran out of words | Already-translated pages keep serving; new or changed text stops being translated | Immediately |
The two rules behind the table
Nothing is retranslated retroactively. A change applies to translation work that has not happened yet. It does not sweep back through text already translated, which is why a glossary rule added late leaves earlier sentences as they were.
A translation you can see is not always the one being served. Universally caches, your page cache caches, and your CDN caches. Clearing only the first changes nothing a visitor sees if the other two still hold a copy. See Clear cache and refresh translations.
Working out which layer is stale
Check in this order, because each step rules out the one before it:
- Open the string on the Translations screen. If your change is not there, it was not saved.
- Load the translated URL in a private window. If the change appears, your own browser was caching. If not, continue.
- Clear the translator cache, then reload in a private window. If the change appears now, Universally was serving its cached copy.
- Clear your page cache, then your CDN. If the change only appears after these, that layer was holding it, and it will hold the next change too.
Skipping to step 3 is the common mistake: it clears the layer least likely to be the problem on a WordPress site with a page cache in front of it.