A professional translator does not work in a text box. Trados, memoQ, Phrase, and Smartcat carry translation memory, term bases, QA rules, and project management as one workflow. Adding machine translation to that is not about replacing the translator -- it is about removing the blank-page step so that human effort goes into review and judgment instead.
Understand where MT sits in the chain
In a standard CAT workflow, an incoming segment passes three checks in order: translation memory for exact or fuzzy matches, the term base for renderings that must be enforced, and only if neither produces a usable result does machine translation fill the gap.
That order matters. MT is the fallback, not the first choice. Configuring MT ahead of TM overwrites years of accumulated memory, which means discarding an asset you already paid for. The correct setup places MT below your fuzzy match threshold -- for example, call MT only when the TM match rate falls under 75%. The translation memory documentation defines how those rates are calculated.
Three integration paths
The first is plugin-based. Trados Studio and memoQ both have official or community-maintained plugins; install, paste an API key, and you are running. Lowest setup cost, and a good fit for individual translators and small teams. The second is native platform integration -- Phrase, Smartcat, and Crowdin expose MT engine selection directly in project settings, which suits collaborative projects.
The third is building your own layer on top of the text translation API. It sounds like more work, but it is the only option once you need processing around the call: switching glossaries per client, applying different style rules per content type, or writing results into your own QA system. The API quickstart has a minimal working example.
Keep glossaries synchronized in both directions
Your CAT tool has a term base and your MT engine has a glossary. If those two drift apart, the machine draft and the QA rules fight each other every day -- the translator fixes a term, QA flags it again, and everyone burns time.
The practical fix is to treat the CAT term base as the single source of truth and export it into the format the MT engine reads on a schedule. Downloading and sharing glossaries covers the format requirements. If terminology changes often, automate that export through the API and hook it to term base updates.
Tags and placeholders are where things break
Technical documentation and software strings are full of inline tags -- bold, links, variable placeholders, conditional text. If machine translation does not understand them, they end up misplaced or dropped entirely, which triggers tag mismatch errors on import and invalidates the whole segment.
Enable tag handling on the API call so the engine treats markup as untranslatable structure and repositions it according to target-language word order. HTML and XML tag handling goes deeper on this; teams working on technical content should read it before configuring anything.
Measure the gain with post-editing distance
Once MT is wired in, how do you prove it helped? The industry metric is post-edit distance (PED) -- the proportion of the machine draft that changed before final delivery. Most CAT tools can compute it from the edit log directly.
As a rough guide, a PED under 30% means the draft is genuinely usable and translators are polishing. Above 50%, check the configuration: the glossary may not be applied, the domain may be a poor fit, or the content type may simply be wrong for MT -- marketing taglines and creative copy usually are. Track PED per content type and let the numbers decide where MT stays on and where it gets switched off.
The value of CAT integration is not speed. It is letting each part of the chain do its job: memory handles reuse, the term base handles consistency, MT handles the blank page, and the translator handles judgment. Configured correctly they reinforce each other; configured badly they cancel out. For integration detail, see the official SDKs or start from the developer page.