Translation memory

There’s nothing to set up. Every block whose translation you approve (the active version) is added to your memory automatically, whether it is your own work or your team’s.

Imported memories count too: bring a TMX or XLIFF file in and its segments are searchable from day one.

Open the Memory panel in the editor sidebar and it searches for the block you’re on automatically. Matching goes by meaning as well as wording: a semantic search is fused with exact and fuzzy text matching, so a past translation surfaces even when the new sentence is phrased differently.

Each result shows the source, the past translation, and a percentage match (how close the text is). Enhance results adds an AI re-rank. Copy a translation or insert it straight into the block.

Four modes search beyond translations:

• Blocks: approved source → target pairs from your past work.
• Comments: past discussion threads, tagged open or resolved.
• Chat: collaboration chat and assistant conversations.
• Documents: ranks whole documents by relevance, to find where similar work lives.

Your matches go to the model as reference when you translate, proofread, or run a Find, so the machine translation reuses your established wording rather than guessing a fresh phrasing each time.

A glossary keeps individual terms consistent; the memory keeps whole sentences consistent, and does it inside the AI’s output.

In the editor, memory is on by default and grounds every run unless you turn it off for that run: Skip TM under the ⋯ in the bar below a paragraph, or the Translation memory switch under Advanced in the run dialog’s Customize step.

Fast-tier models are the exception: memory needs a Standard or Pro model.

Each batch run and workflow step follows your translation memory settings. Set those defaults below.

When a translation was generated with memory matches in its prompt, the block’s header shows a small Memory chip with a count. Click it to see what the AI was given: each remembered wording with its match %, the document it came from, any previously rejected alternative of that segment, and the reviewer discussion behind it. That shows why a wording looks the way it does.

Each entry carries one of two labels. Reused means the output measurably adopts that remembered wording; Referenced means the model was shown it as reference, but the output doesn’t reuse the wording.

The Memory panel shows the same list pinned at the top as “Used for this translation” for the block you’re on.

No chip means that version was generated without memory: it was switched off for the run, the model tier doesn’t use memory, or there were no matches.

Versions translated before this feature existed don’t show a chip either.

Wherever you run one of those actions (the ⋯ in the bar below a paragraph, Advanced in the run dialog’s Customize step, each workflow step), the controls split into two groups.

In the editor they sit in a collapsible Search & filters section of the Memory panel, kept closed by default so the matches get the room; open it when you want to change what the search returns.

Search decides which matches come back. Its scope searches everything you can access by default, on the current document’s source → target language pair. Narrow it to a project, a team, or only this document; the last recalls nothing but that document’s own approved segments, so a corpus like your app’s UI strings stays isolated from the rest of your work. Alongside scope sit exclude the current document, include other language pairs to widen the net, and an AI re-rank of the top hits for relevance.

AI context decides what the model sees with those matches: include past discussions (comment threads) as matches, include up to 2 earlier alternatives of a segment, and Text around matches, which attaches the blocks surrounding each match to the prompt so the model sees how the wording was used.

Translation memory is free on every plan, including Free. Building and reusing your memory never costs credits; only AI work on your text does.

The Translation memory page under the Library menu (also reachable from the Manage TM settings link in the editor’s Memory panel) sets the defaults every document inherits unless it has its own override.

It covers whether memory is on by default in the editor, the Search and AI context options above, and what appears in results.

That last setting decides which document statuses may be searched and which projects to exclude. By default only approved work (Delivered or Paid) is searched, and you can widen that.

One more result control lives here: Include untracked documents — on by default. The status filter admits only the statuses you allow, which would drop any document with no status set (usually bulk- or API-imported content that never carries one); this switch keeps those documents in the memory. Turn it off to restrict the memory strictly to status-tracked work.

• Defaults can be overridden per document. The editor’s Memory panel writes the change onto that document.
• Each workflow step has a memory setting with a “Use document default” option, which inherits what the document, or its team, resolves to.

A team owner can set a team translation-memory policy and enforce it.

On team-owned documents, members then get only the memory on/off switch; the Search and AI-context settings and the result filters follow the team’s policy. Personal documents always follow your own defaults.

The document’s owner can still override the policy for a single document, covered next.

Yes, if you own the document. Even under an enforced team policy, the document’s admin (the team owner on a team document, or you on a personal one) can still change that one document’s Search and AI-context settings from the Memory panel.

The change becomes a per-document override that beats the enforced policy for that document only, so you can switch a single document to Only this document while the rest of the team’s work stays on the team policy.

Everyone else sees those controls read-only and keeps just the memory on/off switch. See roles & permissions.

An empty Memory panel usually has one of three causes.

The document-status filter (most common). By default the memory draws only on finished work: documents you’ve marked Delivered or Paid. Anything still at an earlier status (Quoted, In progress, In review) is left out.

Documents with no status at all (bulk- or API-imported content, or anything you never put on the board) stay included, because Include untracked documents is on by default.

To fix it, set a document’s status from the status chip in the editor header or the ⋯ menu on the dashboard. You can also widen which statuses count under what appears in results on the Translation memory settings page, or turn Include untracked documents off to restrict the memory to tracked work only.

For imported content, see Bring existing translations.

The language pair. The panel searches your current document’s source → target pair, so if you have no earlier work translating from this language into this one, there’s nothing to match. Check the document’s languages are right, and turn on Include other language pairs in the panel to search across pairs.

A memory you just imported. A TMX or XLIFF you’ve only just brought in is searchable by text straight away, but its meaning-based matching is built in the background. Give it a short while, then run the search again — segments phrased differently from your query will start to surface once indexing finishes.