AI Translate can now store the translations it gets back from the AI provider and reuse them when the same text is translated into the same language again. A repeated string costs one request instead of one per occurrence. Deduplication within a single run falls out of the same mechanism: the batch translates one field at a time, so the first occurrence's cache write lands before the second one's lookup.
Existing sites
Nothing changes until you opt in. The new cache_translations setting in ai_translate.settings is set to FALSE on updating sites by ai_translate_post_update_disable_translation_cache(). To switch it on, tick Cache translation results at /admin/config/ai/ai-translate. New installs get it enabled.
How entries are keyed and cleared
Translations live in the module's own ai_translate cache bin (cache_ai_translate), which can be flushed on its own; a full cache rebuild clears it too. Each entry is keyed on the source text, the language pair, and the provider and model that produced it - so editing the source text or switching model translates afresh, and switching back reuses what the earlier model produced. Entries are tagged with ai_translate.settings and the prompt config entity, so editing a prompt discards the entries that used it; a change the module cannot see (a model parameter edited elsewhere in the AI module) does not.
A cache read or write that fails is logged and falls through to the provider, never failing a translation. Empty responses are not stored.
Leave it off if…
- You implement hook_ai_translate_translation_alter(). The lookup happens before the provider is built, so a hook varying the prompt or provider per request is bypassed on a cache hit.
- You rely on AI Observability and this functionality would interfere. A cache hit never reaches the provider, so no events fire and no token usage is recorded - a fully cached run shows no activity.
Also expect markup to count: Read more and
Read more
are two entries and two provider calls. See docs/configuration.md for the full description.
