Patois.

Docs · Features

Translation memory

Every approved translation is remembered, so the same sentence never has to be translated, or paid for, twice. Translation memory fills exact matches for free, offers fuzzy matches as suggestions, and can catch a workflow up when a document's memory has moved past what was last translated.

What it does#

A TM entry is one stored source and target pair, for one language pair, inside one project, written automatically when a segment is approved or imported from a TMX file, the industry-standard interchange format. Three kinds of match can come back: an exact match, where the stored source is identical to the segment being translated and can be applied straight into a document without a model call; a fuzzy match, scored as a percentage and shown as a suggestion or as an example in a translate step's prompt; and an optional semantic match, found by meaning rather than characters, off by default and available once embeddings are configured.

Inside a workflow, a TM match step pre-fills any segment with a qualifying memory hit before an engine runs, and locks it so later steps do not overwrite it: soft-locked by default, meaning it still enters quality review, or hard-locked when the policy that routes perfect matches into review is turned off. Each TM match step is tunable on its own: a fill threshold for how close a match has to be to count, a lock mode for below-perfect fills, and a choice of which project TM pools it reads. A fuzzy fill only ever lands when the numbers, URLs, and variables in the segment and the memory entry match exactly, so a wrong number can never be silently filled in.

A TM match step also self-heals: if a segment's source has a perfect memory match but the machine-translated target on record has drifted away from it, the step re-fills the segment from memory and locks it, rather than leaving the drift for a later translate step to reproduce. Your own edited or approved text is never touched by this, only machine-generated text.

Getting started#

  1. If you already have a TMX file from a previous tool, import it into the project.
  2. Otherwise memory fills itself: every segment someone approves in the editor is written back automatically.
  3. Before running a full translation, apply perfect TM matches on the document. Anything with a perfect match is filled in without spending anything.
tm import PROJECT_ID file.tmx --source en-US --target de-DE
tm search "renewal notice"
doc apply-tm DOC_ID de-DE
tm export PROJECT_ID file.tmx --source en-US --target de-DE

The same actions are available on the TM page and the project page in the web UI.

Note

A project can also attach another project's memory as a TM source, so your runs match against it too. This is a reference, not a copy: no entry is duplicated, and improving the source project's memory does not change what your own project has stored.

Works with#

  • Workflows: a Translate step with TM examples on shows the model similar past translations by default, and segments filled by a perfect TM match are soft-locked so a normal translate step skips them.
  • Documents: approving a segment in the editor is what writes to TM; applying perfect TM matches on the document page is what reads back out of it in bulk.
  • Glossary: TM remembers whole sentences you have already translated, while the glossary enforces individual terms; when the two disagree about a term, the glossary wins.
  • Engines: a TM hit costs nothing, since no model call is made. More memory is the cheapest way to reduce spend.

Current limits#

Current limits

Importing a TMX under the wrong locale pair produces entries that never match anything. The import reports which locales the rows were actually stored under, so check that output rather than assuming the pair was correct.

Translation memory does not deduplicate across projects. The same sentence stored in two different projects is two separate entries, and improving one does not improve the other.

Semantic matching is off by default; with it off, matching is exactly the classic exact-and-fuzzy lookup. Turning it on later, or changing the embedding model, requires a backfill of existing entries before semantic matches appear.

A segment that fails an inline-tag or number-integrity check is held out of memory. Approving it cannot pass damaged text into shared memory.

A workflow that relies on TM matching alone, with no translation step, can leave some segments unmatched. When that happens, a document carrying unmatched, empty targets from that run is held from delivery until a person reviews and approves shipping it with those segments empty.

An attached TM source only widens what a project matches against. Write-back, the project's own TM count, TMX export, browsing and concordance search all stay scoped to the project's own memory, and attachment does not chain: a source's own attached sources are not included.