Rich text tags in translation: keeping markup alive across languages

Most game text is not plain text. A single line of dialogue or a tooltip commonly carries inline markup — color tags to highlight a keyword, bold or italic for emphasis, ruby annotations for pronunciation guides, icon tokens that get swapped for a button glyph at render time. All of this markup has to pass through translation and come out still valid, still paired, still in the right place relative to the words around it.

This is a narrower problem than translation quality in general, and a much more mechanical one — which is exactly why it is worth handling separately from linguistic review.

What the markup actually looks like

Regardless of the specific syntax a project uses, inline markup in game text is almost always some form of paired tokens wrapping a span of text, similar in shape to HTML or BBCode.

You found a <color=gold>legendary sword</color>!
Press <icon=button_a/> to continue.
The <ruby=en>English</ruby> reading is shown above.

The common ways tags break

The same handful of mistakes account for nearly every broken tag a translator introduces, usually without meaning to.

• Unclosed pairs — an opening tag makes it into the translation but its matching closing tag is dropped, so every following line of text inherits the formatting
• Reordered nesting — when tags are nested, translation can reorder words enough that the closing tags end up crossing each other instead of closing in the reverse order they opened
• Translated tag names or attributes — a translator working quickly can translate the word inside the tag along with the surrounding sentence, breaking the token the code is looking for
• Whitespace introduced inside a tag — a stray space added while retyping a tag (<color = gold> instead of <color=gold>) can be invisible to the eye but invalid to a strict parser
• A tag moved to wrap the wrong span — the translated sentence reorders words, and the tag ends up highlighting a different word than the one that was meant to stand out

Rules worth giving translators up front

A short, explicit set of rules prevents most of this before it happens, rather than catching it after the fact.

• Never translate anything inside angle brackets or other tag delimiters — the content of a tag is code, not prose, even when it looks like a word
• Every opening tag needs its matching closing tag in the translated line, in the same relative order
• It is fine, and often necessary, to move a tag pair to wrap a different word if word order changes — but the pair must move together
• Do not add or remove spaces immediately inside tag delimiters

Why this check is mechanical and cheap

Unlike judging tone or naturalness, verifying tag integrity does not require understanding the target language at all. A translated string either has the same set of tags, correctly paired and nested, as its source string, or it does not — that is a structural comparison a script can make in constant time, on every string, on every run.

This makes tag-balance checking one of the highest-value automated checks in a QA pipeline: it costs almost nothing to run, produces no false judgment calls, and catches a class of bug that is otherwise invisible in a spreadsheet review and only shows up once the broken formatting is on screen.