Patois.

Docs · Features

Vendors

Vendors are first-class external translation and review partners. A workflow can dispatch its packaged text to a human vendor and wait for a signed return, with rate cards, an optional quote-and-approve spend gate, and a reject-and-rework loop, all without leaving the run.

What it does#

A vendor is held as a first-class record: a name, a connection, a transport protocol, and a rate card, linked to the customers it may serve. A workflow's external step hands its packaged text to a linked vendor and pauses the run until the vendor returns it, so a vendor is a workflow capability rather than a side channel. Delivery is either native, an automated signed exchange, or manual, where an operator carries the package out and the return back in; the protocol is fixed at the moment a package is sent, so changing a vendor's setting afterward only affects future dispatches.

A rate card prices a dispatch by translation-memory leverage: how much of the work is repetition, exact matches, fuzzy matches, or genuinely new text, turned into a human-spend estimate. A vendor can optionally require a quote and an operator's approval before work proceeds, a deliberate spend decision kept separate from dispatching. If a delivered leg needs correcting, it can be rejected and re-dispatched to the same vendor with structured feedback; rework rounds are capped, after which the run escalates to a person rather than looping indefinitely.

The outbound package also renders as XLIFF 1.2, the interchange format most vendor-side CAT tools open, and an XLIFF return is accepted anywhere a JSON return is.

Getting started#

  1. Add a vendor and set its connection, protocol, and rate card.
  2. Attach an external step to a workflow, pointing at the vendor. When a run reaches it, the packaged text is sent and the run waits.
  3. Track what is out, approve a quote if the vendor requires one, and let the return resume the run.
vendor add "Acme Translations"
vendor rate-card show 5
vendor dispatches
vendor quote --dispatch-id 42 --amount 250
vendor approve-quote --dispatch-id 42

The same lifecycle is driven from the Vendors page and the workflow builder in the web UI.

Works with#

  • Workflows: an external step dispatches the vendor and pauses the run until the signed return arrives, then resumes it.
  • Documents: a dispatch leg packages a document's segments, and the return commits translated text back through the same write path a normal translation uses.
  • TM: a leg's translation-memory leverage breakdown is what a rate card prices into the human-spend estimate, so better TM coverage lowers the vendor quote too.
  • Engines: vendor spend sits alongside model spend in the same ledger, so a vendor leg and an engine call are two priced lines on one run.
  • Queries: an open query on a segment that is out with a vendor rides out with the package, and the vendor's shared reply comes back as a post in the same thread.

Current limits#

Current limits

If a dispatch fails to send, it is retried automatically; if it keeps failing past the retry window, the run escalates to a human review pause rather than dropping the work silently.

Rework rounds are capped, one round by default. Past the cap, the run escalates to a person instead of looping on the same vendor indefinitely.

Deleting a vendor fails while a workflow step still selects it or a dispatch still references it. It never cascades and silently orphans work in flight.

A quote-gated dispatch parks awaiting the vendor's quote before any work proceeds. If the vendor never submits one, the dispatch simply stalls in that state until an operator withdraws it; there is no automatic timeout.

Vendor spend is tracked as an estimate, priced from the leg's memory-leverage breakdown, until the vendor reconciles an actual cost on its return. Model spend and vendor spend are always reported as two separate figures, never summed into one number.

On the XLIFF manual path, queries travel out to the vendor but comments only return through the vendor's own return path, a third-party CAT tool's arbitrary notes are never silently turned into customer-visible queries. A vendor's own internal notes stay internal unless the person writing them explicitly marks them to share, and that choice discloses that both the buyer and the buyer's own client will see it.