Translation management
A translation management system manages the work. It does not translate the file.
That distinction is where most agency pain lives. The TMS tracks projects, assigns linguists and holds the memory. The document still has to be taken apart, translated and put back together — and that is the step that breaks.
We are not a TMS. We are the engine a TMS calls.
What a TMS is good at, and what it is not
Both halves of this are true at once. The second half is why we exist.
Good at: managing the work
Project tracking, assignment, deadlines, translation memory, billing, reporting. This is real software solving a real coordination problem.
Good at: holding the memory
A translation memory is the agency's accumulated asset. Nothing here changes that.
Not built for: the document itself
A .pptx is not a bag of strings. Rebuilding it around translated text — slide by slide, with the layout intact — is a format-specific engineering problem, per format.
Not built for: page-level judgement
Real documents are messy. Half scanned, half digital, one page with a chart that needs different handling. A segment-based workflow has no natural place to make that call.
The gap, stated plainly
Segments are the right unit for memory. They are the wrong unit for layout.
Segment-based tools break a document into translatable units. That works beautifully for text and memory reuse. It also throws away the information about where that text physically sits — the position of a chart, the fit of a headline in a text box, the numbering across a section.
Some of that information can be carried through markup. A lot of it cannot, which is why format-preserving translation has stayed a hard problem rather than a solved one.
We treat the page as the unit: inspect it, decide how to process it, translate it, put the result back where it came from, then check the result visually. Segments still matter — terminology and memory are enforced per term and per document — but they are not the organising principle.
What we add to the stack you already run
Positioned as a complement, not a replacement. Each of these is a capability we run today.
Document intake and classification
Files arrive and each page is classified — digital, scanned, image-heavy — before any translation happens.
Format-preserving translation
Translated text written back into the original layout across PDF, DOCX, PPTX, XLSX and legacy Office formats.
Glossary enforcement
Up to 2000 terms per glossary, applied during translation. Your TMS keeps being the system of record for the term base.
Independent visual QA
A second model reviews the output before delivery. The page that failed gets caught on our side, not by your client.
Region-level repair
A wrong area is marked and reprocessed on its own — restored, retranslated or kept — instead of rerunning the document.
Batch handling with resume
Up to 50 files per submission and 1000 pages per PDF. Interrupted batches resume from the last completed page.
TMS, raw MT, and this
Three different layers. They are not substitutes for each other, and the table compares capability only — no pricing from anyone.
| Row label | Us | Raw MT / cloud translation APIs | TMS platforms |
|---|---|---|---|
| Multilingual | Configured to your markets | A fixed list | A fixed list |
| Format preservation | Layout written back in place | Text or a rough file | Not an engine |
| Per-page processing plan | Each page routed on its own | One call, no quality control | Manual workflow |
| Multimodal input | Five source classes, five paths | Mostly text only | No |
| What you receive | Finished files | A block of translated text | Process management |
| Who owns the quality | Us | You | You |
TMS questions
Do we have to replace our TMS?
No, and we would not suggest it. The pattern is that the document pipeline runs through us while the TMS keeps managing projects, assignments and memory.
Can you write back into our translation memory?
Not as a standard capability. Memory belongs to your system of record. If you need an exchange between our output and your memory, that is scoping work — tell us the interface.
Is this a CAT tool?
No. A CAT tool is where a linguist works. This is the pipeline that produces a finished document, which a linguist can then review if your process requires it.
What happens to documents that are partly scanned?
Each page is classified separately, so a mixed PDF is a normal case. Digital pages and scanned pages take different paths inside the same file.
How does terminology stay consistent with our term base?
You upload the term list — TXT, CSV or XLSX, up to 2000 terms per glossary — and it is enforced during translation. Your term base stays where it is.
We build a TMS. Can we embed this?
That is the platform vendor conversation, and it is scoped per engagement rather than sold as a package. Start there and we will tell you what it takes.
See what the document pipeline does with your file.
The TMS question is easier to answer with a finished document in front of you than with a feature comparison.
- One real file
- Returned finished
- You judge the layout