Fifty files, one upload, one delivery

Real work does not arrive as one tidy document. It arrives as a ZIP with fifty files in it, mixed formats, sent at five in the afternoon with a Monday deadline.

Handling that well is not a matter of looping over the files. Four things have to be true at once, and each of them broke something for us before it worked.

1. Each file gets the right pipeline

A batch is rarely homogeneous: a couple of Trados bilinguals, some Word documents, a spreadsheet, a scanned PDF someone dropped in by mistake. Each one is routed to the pipeline built for its actual format, by extension, not by whatever the ZIP was labelled.

2. One file failing does not kill the batch

Files are processed as independent jobs under a parent. A corrupt document or an unsupported extension in the middle of the batch fails on its own and reports itself, while the other forty-nine keep going. The alternative — the whole batch dying at file 31 — is how an afternoon disappears.

3. It comes back as one delivery, not fifty

You get a single ZIP with the original folder structure and the original filenames. Which sounds obvious until you meet the Windows path limit: a long client name plus a long project name plus a long filename produces an archive some machines silently refuse to extract. The archive name is capped and suffixed; the names inside are never touched, because those are what your client is expecting.

4. It is one review, not fifty

The whole batch opens as a single review, and this is where the interesting failure lived. Corrections were being applied to the parent — which holds no artifacts, because every file is its own job — so a reviewer could work through fifty-eight files and the delivery would come back without a single one of their changes. Silently.

Now edits are routed to the file they belong to, namespaced per child job, and the deliverable is regenerated from them. And the cross-batch consistency pass runs across all fifty files at once, so the same source sentence cannot come back translated four different ways depending on which file it landed in.

None of this is a feature you can see in a screenshot. You notice it exactly once — the first time you send a batch that would have broken somewhere else.