Understand Translation Memory

TranslateSense translation memory is the database-backed store used to keep extracted source strings and translated results. It can reduce repeated provider requests when a matching string hash and target language already have a saved result. It is not a glossary, a translation editor, or a guarantee that every translation will be reused.

How a string is identified

The parser extracts fields according to the active editor builder and XML rules, then filters each value before storing it. The filter decodes HTML entities and replaces non-breaking spaces, zero-width spaces, and left-to-right or right-to-left marks with ordinary spaces. For HTML, it parses the markup and can unwrap single-child wrapper elements while retaining the selected node’s inner HTML; it does not simply remove every HTML tag. Empty or non-text values and values recognized as email addresses, URLs, or asset paths are skipped. TranslateSense creates the shared string hash with MD5 of the filtered string, and the package hash with MD5 of the widget or field identifier, an underscore, and the filtered string. These hashes are internal lookup keys, not quality scores or security features.

A package also records the post ID, source-language code, editor type, widget name, and field key. The saved translated result is associated with a string ID and target-language code. This lets TranslateSense reuse a matching result across posts when the shared string hash matches, rather than requiring the same post ID.

What makes a translation reusable

The extracted source text and its hash must match a stored string or package.

The target-language code must match the requested target language.

A non-empty cached translation must exist.

Server-side provider results can be persisted; Chrome Built-in AI is excluded from persistent result caching in this version.

The persistent cache key does not include the provider, model, or prompt. A matching cached result may therefore be reused after you change a provider or prompt. If you need to compare a new provider or prompt, test with a new source phrase or another controlled test case and inspect the translated result before publishing.

Test translation reuse safely

Choose a small test post and confirm its source and target languages in Polylang.

Translate one short phrase with your configured provider and review the result.

Run the same workflow again without changing the source phrase. A matching cached result may be reused, so a new provider request is not guaranteed.

Change the test phrase slightly and repeat. The altered string may produce a different hash and require a fresh translation.

Review the target page after applying translations; the cache stores string results, not a promise that the full page layout or every field was translated.

If the result seems outdatedFirst verify the source text, target-language code, selected provider, and the fields extracted by the editor builder. Then review the XML rules for any skipped Gutenberg or Elementor field. The cache-cleanup routine runs on a daily WordPress cron schedule and removes translation rows older than five days based on updated_at, but the inspected UI does not expose a cache-clear button. Do not delete rows directly without a database backup and a clear recovery plan.

For broader cache storage and cleanup details, read Translation Memory and Database Caching. For field extraction, see Understand Content Field Mapping and Update Elementor XML Rules.

Screenshot to add: [Translation memory lookup and reuse example]