Translation memory

There’s nothing to set up. Every block whose translation you approve (the active version) is added to your memory automatically — your own work and 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 is by meaning, not just wording — a semantic search fused with exact and fuzzy text matching, so a past translation surfaces even when the new sentence is phrased differently (recall a fuzzy-only CAT memory misses). 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.

This is the part that sets Transept’s memory apart. Your matches aren’t only there for you to copy — they’re passed 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 — it grounds every run unless you hit Skip (the Memory button on the block toolbar, or in the batch dialog). 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 and Transept names the decisions 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 — so you can see not just that a wording was reused, but why it looks the way it does.

Each entry is labeled honestly. 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 simply no matches. Versions translated before this feature existed don’t show a chip either.

Wherever you run one of those actions — the block toolbar’s Memory button, the batch dialog, and 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 Context — attach 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 words — only translating new 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: whether memory is on by default in the editor, the Search and AI context options above, and what appears in results — which document statuses may be searched (by default only approved work — Delivered or Paid — which you can widen) and which projects to exclude.

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.
• And per workflow step: each step’s memory setting has a “Use document default” option that inherits whatever 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. An enforced policy is not quite absolute, though: the document’s owner can still override it 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 on an enforced document and keeps just the memory on/off switch.

An empty Memory panel is almost always one of three things — not a bug.

The document-status filter (most common). By default the memory only draws 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. Set a document’s status from the status chip in the editor header, or the ⋯ menu on the dashboard; 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.

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.