How to handle inline tags and placeholders in AI translation without breaking them

The file came back clean. Formatting held, terminology was consistent, nothing in the target text looked wrong. Then the client's web team loaded it and a third of the product page rendered as visible junk, because {{product_name}} had been translated into Spanish as {{nombre_del_producto}}. Inline tags and placeholders are the quietest failure in translation work: nothing looks broken in the document you are proofreading, and the damage surfaces days later in somebody else's system. We see a lot of DOCX, XLSX and PPTX files go through AI translation, and markup integrity is the thing that breaks most often when people assume the model will simply handle it.

Two kinds of markup, two kinds of damage

It helps to separate what you are protecting, because the two families fail differently and need different rules.

The first family is formatting markup that belongs to the document itself. A bold span inside a sentence, an italicised product name, a hyperlink anchored to three words, a footnote reference. In a CAT tool these appear as numbered inline tags. In XLIFF, the OASIS standard that most tools fall back on for interchange, they are paired or standalone elements inside the segment. Break one of these and the document still opens, but the bold lands on the wrong word, or a link swallows the rest of the paragraph.

The second family is placeholders that belong to a system downstream of the document. Mail-merge tokens like {{customer_name}}, printf-style arguments like %s and %1$s, ICU message syntax, environment-style variables like ${count}, and Excel formulas or cell references sitting in cells you were asked to translate. These are not formatting. They are instructions for software that will read the file after you are done with it. Break one and nothing renders oddly in Word. Something fails in production instead.

The practical difference: formatting tags usually have to move, because word order changes between languages, and your job is to move them correctly. Placeholders usually have to stay byte-identical, and your job is to stop anything from touching them at all. Treating both with one blanket "don't change the tags" instruction is how teams end up with bold in the wrong place and a broken merge field in the same file.

Worth sorting your file into these two buckets on sight, before you write a single rule. If a token would mean something to a developer, it belongs in the second bucket and gets frozen. If it only affects how a human sees the page, it belongs in the first and gets moved with care.

Why inline tags and placeholders break during translation

A language model reads a segment as text. It does not know that {{product_name}} is a contract with a templating engine. It knows that the string contains two English words and that the surrounding sentence is being rendered into Spanish, so it does the consistent thing and translates them. This is not a bug in the model's reasoning. It is the model doing exactly what it was asked to do, to content that should have been fenced off.

Several patterns show up again and again in our experience:

Translation of placeholder contents, as above. Anything that looks like a word gets treated like a word, especially in snake_case or camelCase, which models read fluently.

Character substitution inside tokens. We once reviewed a PPTX where speaker notes contained %1$s and the Russian output came back with a Cyrillic с in place of the Latin s. Visually identical in the slide. Completely dead in the application that consumed the strings.

Tag count drift. When a model rephrases a sentence, it may merge two adjacent bold spans into one, drop a redundant tag, or helpfully "fix" inconsistent markup in the source. The target is cleaner than the source and no longer round-trips.

Reordering that separates a pair. German and Japanese word order moves the emphasised phrase somewhere else in the sentence. A model that moves the opening tag but leaves the closing tag anchored to the old position produces bold that runs to the end of the paragraph.

Whitespace normalisation around tags, which sounds trivial until a CAT tool rejects the segment on import.

The failure rate climbs with tag density. One tag in a short sentence is usually fine. Eleven tags in a sentence, which is what you get when an author typed over partially bolded text in Word and left behind a trail of separate formatting runs, is where things fall apart. Source documents built by people who were not thinking about translation produce the worst cases.

Fix the source before the model sees it

Most of the work that actually pays off happens before translation starts, and almost none of it is interesting.

Start with an inventory. Run a regex pass over the extracted text and list every distinct token pattern you find: \{\{[^}]+\}\}, %\d*\$?[sd], <\d+>, \$\{[^}]+\}. Count occurrences per pattern. Five minutes of this tells you whether you are looking at a plain document or a file with three different placeholder conventions in it, which happens more often than you would expect when content has been pasted together from several sources.

Then clean tag soup. In DOCX, collapse redundant adjacent runs that carry identical formatting. Most of the eleven-tag sentences we see are really two-tag sentences wearing a costume, and flattening them before import removes the problem instead of asking the model to navigate it. Our guide to translating a DOCX without breaking the layout goes deeper on the document-structure side of this.

Next, decide policy per pattern and write it down. Does {{city}} stay verbatim, or does the client expect the token name itself to be localised because their system uses language-specific keys? We have had both. Ask. Guessing here is expensive.

Finally, exclude what should not be translated at all. In XLSX work this matters more than anywhere else: a price list we handled had SKU codes, formulas, and merge tokens scattered through the same sheet as the descriptions. The original run translated {{sku}} into German as {{artikel}}, nobody caught it in review because the German read perfectly, and the client found out when 600 printed labels showed literal curly braces. Marking those columns as non-translatable before import would have cost two minutes.

Writing tag rules the model will actually follow

Generic instructions produce generic compliance. "Preserve all tags and placeholders" is weaker than it sounds, because the model has to infer what counts as a tag.

What works better is enumerating the exact patterns present in this file, with an example of each, and a stated action. Something closer to: tokens matching {{...}} are copied character for character, including case and underscores, and are never translated; numbered tags like <1> and </1> may be repositioned to follow target word order, but each opening tag keeps its closing partner and the count per segment stays equal to the source; %s and %1$s are copied in Latin characters only.

Two things make a measurable difference beyond the wording. First, pinning placeholders in the glossary. If the terminology resource the translation prompt draws on lists {{product_name}} with itself as the target, you have given the model a positive instruction instead of a prohibition, and positive instructions hold up better across long documents. Second, keeping segments short. Tag errors cluster in long segments with many tags, so the preparation choices that shorten segments also reduce markup damage.

Be honest with yourself about the ceiling here. Prompt instructions reduce the error rate. They do not take it to zero, and we would not stake a delivery on them alone. On a German manual we worked through, inline emphasis tags survived in the large majority of segments and still moved incorrectly in a handful, all of them sentences where the clause order inverted. That is a perfectly workable outcome, but only if something downstream catches those few. Which brings us to the part people skip.

Verify markup with a script, not with your eyes

Reviewers are good at language and bad at counting angle brackets. After three hundred segments, %1$s and %1$5 look the same. This is machine work.

The baseline check is a token diff: extract every match for each pattern from the source and the target, compare the multisets, and flag any segment where they differ. This single check catches translated placeholders, character substitutions, dropped tags, and duplicated tags. It takes a short script and runs in seconds on a whole document. If you work in a CAT tool, the built-in verification in Trados, memoQ or Phrase does the tag-pair part of this already, and dedicated QA tools like Xbench and Verifika do it across files. Use what you have.

A second check worth adding is a round-trip render. Assemble the translated DOCX or PPTX, open it, and look at the pages where tags were dense. Bold in the wrong place is obvious to a human eye and invisible to a token diff, because the counts are fine and only the position is wrong.

There is also a cheap sanity check for XLSX work specifically: compare the count of cells beginning with = in the source workbook and the delivered one. If a formula was translated into text, that number drops, and you find out in one line of code instead of during the client's next recalculation.

For software strings, pseudo-translation before the real job is the cheapest insurance in the whole process. Replace every translatable character with an accented variant, leave placeholders alone, push the file through the client's system, and see what breaks. You find out that their renderer chokes on a particular token before a translator has spent a day on the content.

QA frameworks have caught up with this. MQM treats markup and formatting problems as their own error category rather than filing them under accuracy, which is the right call: a broken placeholder is not a mistranslation, it is a structural defect, and it needs its own gate in the process. If your pre-delivery QA routine has no markup step, add one.

The placeholders you cannot protect

Some cases cannot be solved inside the translation step, and pretending otherwise wastes everyone's time.

Grammatical inflection is the big one, and it is the case we get asked about most. {{city}} works fine in English, where "in London" and "from London" leave the noun alone. In Russian, Polish or Finnish the city name needs a case ending that depends on the preposition, and the placeholder delivers a nominative form. No prompt instruction fixes this. The honest answer is a note back to whoever designed the string, proposing either a restructured sentence that keeps the token in nominative position or a separate string per grammatical context.

Plurals behave the same way. A source that reads {{count}} items assumes two plural forms. Languages with three or four forms need ICU plural syntax or an equivalent, which is a change to the source, not to the translation.

Field codes in DOCX are a related headache. Cross-references, automatic numbering and table-of-contents entries recalculate when the document opens, so what you translate is not always what the reader sees. Translate the display text, leave the field intact, and check the rendered output.

And sometimes the source is simply broken: tokens with typos, two conventions for the same variable, placeholders inside words. Those go back to the client. We have learned to raise them early and in writing, because a markup problem discovered at delivery becomes a quality complaint about the translation, however clearly it originated upstream. A short message at project start listing the tokens you found and how you intend to treat each one costs you ten minutes and settles the question of responsibility before it becomes a question.

If you want the AI step itself to run with this structure in place, SnapIntel takes DOCX, XLSX and PPTX files, prepares a glossary and translation prompt that you review and approve before anything runs, and returns the translated file together with a QA report, so markup rules live in the prompt and glossary rather than in someone's memory.

What to do on your next file

Before you translate, run the regex inventory and write down one rule per pattern you find. Flatten redundant formatting runs in DOCX and mark non-translatable columns in XLSX. Put literal placeholders in the glossary with themselves as the target.

After the model returns the text, run the token diff across the whole file and resolve every flagged segment before a human reviewer touches the language. Then open the assembled document and check the tag-dense pages by eye.

The sequence matters more than any single technique in it. Preparation reduces how much can go wrong, instructions reduce how often it does, and verification catches what is left. Skip the last step and you are relying on a client's production system to do your QA for you.