Patois.

Docs · Features

Documents and the editor

Documents are the actual content. Upload a file, translate it, review the segments a person needs to look at, and export it back in its original format.

What it does#

This is where the actual work lives. Everything else, workflows, glossaries, memory, engines, exists to make what happens to a document better. A project holds one source language, one or more target languages, and belongs to a customer. Inside it, a document is one uploaded file (docx, txt, html, md, po, srt, json, xlsx and more), split into sentence-sized segments per target language.

Each segment carries a status, untranslated, translated, needs review, or approved, and any QA flags a machine check has raised: a glossary or do-not-translate violation, damaged formatting tags, a number that changed, or a translation that reads as a refusal or leaked commentary rather than a real answer. The editor is the side-by-side review screen: source, target, translation-memory suggestions and QA findings together, so a reviewer can approve or correct in one place.

Getting started#

  1. Upload the file into a project that has your target languages.
  2. Apply 100% translation-memory matches first. It costs nothing and removes work.
  3. Translate, or better, run a full workflow so the quality checks happen too.
  4. Review whatever is flagged. The editor shows source, target, memory suggestions and the exact finding side by side.
  5. Approve the segments you are happy with. Approving writes them to memory.
  6. Export the file, or export the whole project as a delivery bundle.
doc upload 7 ./handbook.docx
doc apply-tm 12 de-DE
doc translate 12 --locale de-DE
doc export 12 --locale de-DE --out handbook.de-DE.docx

Works with#

  • Workflows: a workflow always runs over one document and one target language, with a run view showing the path it took, step by step.
  • Translation memory: approving a segment writes it to memory; applying 100% matches reads back from it in bulk, for free.
  • Glossaries: glossary and do-not-translate violations are found on a document's segments and surface as QA flags in the editor.
  • Memory: correcting a translation here and saving is the evidence memory later distills into rules.
  • Evaluations: a document can be snapshotted into an evaluation dataset, a frozen copy including its current translations as references.
  • Engines: translating a document dispatches per-segment engine calls; a translation-memory hit skips the engine entirely.

Current limits#

Current limits

Export is guarded: a document whose formatting tags could not be verified is excluded from a delivery bundle and listed separately, rather than shipped broken.

A milder case is substitution: a segment whose formatting was damaged is exported with its source text instead, so the file stays well-formed; those segments are reported by name rather than silently shipped.

A segment held for review still counts as "translated" in the light summary counts. Use the detailed view to see how many still need a person's attention.

Full-text mode, used where segmenting would destroy meaning, has its own repair tools, and a translated body whose paragraph count no longer matches the source is refused outright rather than exported with a broken positional map.

Tag-damage review is conservative on purpose: any divergence in a segment's formatting tags, including a reorder that keeps every token, counts as damage and blocks export, rather than trying to judge which reorders are harmless.

doc translate from the CLI runs synchronously in your terminal, while the equivalent web button enqueues it as a background job.

There is no free-text "describe what you want" option for a document; the work is the content itself.