Rich Text Is the Real Translation Workflow Test

A headline and a short description can make almost any translation workflow look capable. The real test starts when the source entry contains nested lists, inline links, embedded entries, and formatting that carries meaning.

That is where translation stops being a text problem and becomes a content-structure problem.

Rich text is a document, not a string

Contentful rich text is stored as a tree. Paragraphs contain text nodes. Lists contain list items. Links and embedded entries point to other content. Marks carry bold, italic, code, and other formatting.

Flatten that tree into plain text and the words may survive, but the entry does not.

A dependable workflow has to translate the language while preserving the document:

• headings remain headings
• list items stay in the correct order
• links keep their destinations
• inline entries remain in the sentence where editors placed them
• embedded blocks keep their relationship to surrounding copy

The translation model should never be asked to reconstruct structure that the workflow could have protected explicitly.

The dangerous failures look plausible

Rich-text damage is not always obvious in a translation review. A missing embed can leave a paragraph that still reads naturally. A split list can look like several valid paragraphs. An inline entry can disappear while the sentence closes around the gap.

That makes structural errors more dangerous than a visible exception. The request can be marked successful even though the localized entry no longer represents the source.

Good review tooling makes protected structure visible. Editors should be able to see where embeds, links, and formatting sit without reading raw JSON or trusting that every token survived.

Protect first, translate second

A strong rich-text pipeline separates translatable content from structural content.

Before a model receives the document, the workflow can replace protected nodes with stable placeholders. The model translates the surrounding language. The workflow then restores the original nodes and validates that every placeholder returned exactly once.

This creates clear responsibilities:

• the model handles language
• the application handles structure
• validation catches missing or duplicated protected content

That boundary is far more reliable than asking one probabilistic response to preserve an entire CMS document by convention.

Review the hierarchy, not only the prose

Human review should compare more than sentences. It should also answer:

1. Are all source sections represented?
2. Did list nesting remain intact?
3. Are links and embedded entries still attached to the right context?
4. Did empty source blocks stay out of the translated result?
5. Does the rendered preview match the source page's content hierarchy?

The final question matters because a structurally valid document can still produce an awkward page. Preview reveals whether a translated heading wraps badly, a CTA breaks the layout, or an embed lands in an unexpected visual position.

The takeaway

Rich text is where a translation workflow earns trust. Preserving words is only the first requirement. The system also has to preserve the document editors built around those words.

Treat structure as protected data, validate it before saving, and review the result in the CMS preview. When rich text survives that full path, simpler fields become the easy case they should be.