Reviews waiting on a document

Open the document and look just above the first block. Whenever a run, a glossary auto-build, or a style-guide generation has left you something, a 2 reviews pending heading sits there with a row for each. When there is nothing outstanding, the heading is gone.

Every row has a button that opens it. Review takes you to whichever screen fits: an accept/reject deck for suggested fixes, a triage list for flagged comments, a step-through walkthrough for a locate-only find. Continue reopens a saved glossary review where you left it. Nothing touches your translation until you approve it. And if you’d rather read the findings where they sit in the document, you already can — each flag is a comment on its block, suggestion included (see below).

A run that fans out across several languages adds one row per language, so you can work through them one at a time.

The rest of this article is about a run’s flagged blocks. The other two rows are covered where they are made: a saved glossary review in Build from a whole document, an unapplied style guide in Styleguides.

The three kinds, and how you get into each:

Still there, and still where you type a custom find. Find in the list opens it, and the editor’s Workflows tab has the same box, so you can start a scan even when nothing is waiting.

A review that landed at the end of a run, with nothing downstream depending on it, simply clears from the list once every finding is decided. For a run that paused to gate on the review — its row shows a Paused badge — the later steps are still waiting: approving lets the rest of the workflow continue, and dismissing a paused review cancels those remaining steps (Transept confirms first).

You can leave a review midway and come back — your decisions are saved and the row stays listed until you finish or dismiss it. A parked review never locks your words: you’re charged only for the work already done, and the remaining steps are paid for only if you approve and continue.

Accepting writes the corrected text as a new version of the block. The previous translation stays in the block’s version picker, so an applied fix is reversible with one click, like any other version switch. Accepting also resolves the comments the finding staged on that block, so nothing lingers in the Comments tab afterward.

Reject keeps the translation as it is and resolves the staged comments too. If a fix is close but not quite right, Edit lets you adjust the text before accepting; your edited version is what lands.

Yes. A suggested-fix run leaves each suggestion on the comment it created, so you don’t have to go through the review screen to act on one. Open the comment in the Comments tab and you’ll see a Suggested fix card: the proposed change rendered as a marked-up diff, with Apply and Dismiss right there. View in document scrolls the editor to the block and shows the same diff in place, in the translation column, so you can read the change against the original before deciding.

Applying from a comment does exactly what accepting on the review screen does: the fix lands as a new version and the comment resolves.

The panel behind Find has a “What should we look for?” box, and so does the editor’s Workflows tab. Type a plain-language request — “find inconsistent character names,” “where are the untranslated dates” — and Transept proposes a one-step find: it picks the mode (locate, flag, or suggest fixes) and a model tier for you, and shows the estimated cost.

Run starts it as-is. Expand opens the same find in the workflow builder so you can adjust it first. Either way the result lands back in the editor’s waiting list as a pending review, like any other run.

By default, yes. A find that flags or suggests fixes reads each block’s existing comment threads, open and resolved, before deciding what to raise. Running the same find twice won’t stack a duplicate flag on top of one you already have, and it won’t re-raise something a reviewer already settled. This also means you can steer future scans with a comment: note “this phrasing is intentional” on a block, and the next scan takes that into account.

If you want a clean sweep that ignores the discussion, the Find blocks step in the workflow builder has an Ignore open comments toggle; turn it on and the scan reads only the source and the translation.