For TMS and localisation platform vendors
Your customers keep asking for document translation. Building it is a two-year project.
Wiring a raw MT API into a product produces output your customers will not ship: text without the layout, no terminology control, no quality check. We provide the layer underneath that makes the output presentable — and you keep the customer relationship.
Embedded and white-label arrangements are scoped per engagement.
Why the obvious approach fails
Most platform teams try the raw API first. Here is what they run into.
Text in, text out
A translation API returns strings. Your customers uploaded files. Someone has to reconcile the two, and that someone is you.
Layout is your problem
Rebuilding a .docx or .pptx around translated strings is a format-specific engineering project per file type, and it never quite ends.
Quality becomes your liability
Your brand is on the output. If the translation is poor, the customer does not blame the model — they blame your product.
No terminology story
Enterprise buyers ask how their glossary is enforced. "The model usually respects it" is not an answer that closes a deal.
What we provide underneath
A complete document pipeline, callable from your product. Scoped per engagement rather than sold as a self-service connector.
Format-preserving engine
PDF, DOCX, PPTX, XLSX and older Office formats, plus image input. Translated text is written back into the original layout.
Per-page routing
Each page is inspected and routed on its own — digital, scanned, chart-heavy or failing quality control — instead of one treatment for the whole file.
Independent visual check
A second model reviews the output. This is what keeps bad pages from reaching your customers and becoming your support tickets.
Terminology enforcement
Glossaries up to 2000 terms, enforced during translation. Per customer, per project, whatever your model needs.
Programmatic access
API and agent access scoped to the engagement. Tell us the interface your product needs and we will tell you what it takes.
Private deployment option
For customers who cannot send documents outside their own infrastructure, a private deployment can be assessed as a separate project.
Two ways this usually gets built
Which one depends on how much of the experience you want to own.
Embedded: your product calls our capability, we return the finished document, and your customer never learns where the pipeline runs. The interface between your system and ours is the scoping conversation.
White label: the capability appears under your brand. This involves commercial terms and a delivery shape that we agree per engagement — we do not publish a packaged white-label product, because every platform's requirements differ enough that a package would fit none of them.
Both are engineering projects on the integration side. Neither is a self-service signup.
Where the boundary sits
We are the engine. You are the product. That division is deliberate and it does not move.
We do not sell to your customers, we do not put our name on your interface, and we do not use your usage data to build a competing product. Our commercial interest is that your product succeeds.
What that means in practice: the customer relationship, how you charge for the service, the support relationship and the brand stay yours.
Platform vendor questions
Is there a packaged white-label product we can resell?
No. White-label arrangements are scoped per engagement. Platform requirements differ too much for a package to fit, and we would rather agree terms that match your situation than sell you a box that does not.
Do you sell directly to our customers?
No. We work with the people who deliver translation to somebody else. Selling past a partner into their customer base would end the relationship, and we are not interested in that trade.
How does our customer's glossary get enforced?
Term lists are uploaded per glossary — up to 2000 terms — and applied during translation rather than as a correction afterwards. If your customers keep terms in your system, we scope how to read from it.
Can this run inside our own infrastructure?
It can be assessed. The platform is containerised, so a private deployment is technically possible, but it involves licensing, deployment documentation, handover and offline model arrangements. It is a project, not a configuration option.
What does the integration actually involve?
It depends on what your product needs to do. Tell us the interface and we will map it against what we have. This is scoping work, not a connector you install.
How do we evaluate it before committing?
Same as everyone else: send a real document and we return the finished file. If you want to run it against your own test set, that is part of the scoping conversation.
Show us what your product needs to do.
Tell us the customer-facing experience you are aiming for and we will tell you plainly what it takes to build it on our engine.
- You describe the product behaviour
- We map it against our capability
- You get a straight answer on feasibility