TranslateSense uses a database-backed translation memory to reuse some translated strings. This guide explains how the cache is keyed, what gets cleaned up automatically, and how to troubleshoot results that seem stale. These details describe version 0.0.8; the cache does not guarantee identical output across every provider or content type.
How translation memory is stored
TranslateSense stores source strings, extracted content packages, and translated results in separate database tables. The strings table keeps the original and filtered string plus a string hash. The packages table links strings to a post, editor type, widget name, field key, language, and package hash. The translations table stores a translated string by string ID and target-language code.For translation lookup, the implementation generates an MD5 hash from a widget or field identifier, an underscore, and the string value. It also uses an MD5 hash of the filtered string to identify the shared source-string record. The content parser uses XML mapping rules and editor-specific builders to decide which fields are extracted, so cache behavior depends on what is actually extracted.
When a cached result can be reused
TranslateSense looks up a saved result for the target language. It can match a package hash or a string hash; batch translation performs equivalent lookups for remaining strings. The database key does not include the provider name, so a saved result may be reused even if you select a different server-side provider later. Chrome Built-in AI is excluded from persistent translation-result caching; its translations may be reused within the current workflow through in-memory data.- Unchanged source text and the same hash can find an existing translation for the target language.
- Changing text, the widget identifier, or the extracted field can change the hash and cause a cache miss.
- Provider, prompt, model, and contextual intent are not all represented in the persistent cache key. Reuse therefore does not guarantee that the cached wording matches a newer prompt or a different provider’s preferred output.
Automatic cleanup
The plugin schedules a daily WordPress cron event for cache maintenance. The cleanup routine deletes translation results whose updated_at value is older than five days and package records older than 30 days, then removes orphaned source strings and translations. This is source-code behavior, not a guarantee that WordPress cron ran at a particular time on your site.The source also contains a method that can truncate the translations table, but the inspected version does not expose a documented cache-clearing control in the TranslateSense settings UI. Do not look for a user-facing purge button unless your installed build explicitly provides one.
Troubleshooting checklist
Screenshot to add: [Translation memory tables and automatic cleanup overview]