People searching CAT tool tags, inline tags in translation, translation tag mismatch, copy tags from source to target, formatting tags in CAT tools, or how to translate text with tags without breaking the file are usually solving a technical-language problem at the same time. The words need to move naturally into the target language, while invisible structure—bold, italics, links, footnotes, variables, character styles, XML markers, or other inline formatting—must survive the trip.
A fast translator does not treat those tags as annoying clutter around the “real” sentence. Tags are part of the file contract. Current CAT and TMS documentation still warns that missing, misplaced, or malformed tags can create export failures or broken formatting, while modern editors provide shortcuts for copying and moving them rather than retyping them. The practical skill is therefore not “translate around the tags.” It is move the tags with the span of meaning they belong to.
This article has one dominant job: translate tag-rich segments quickly without losing target-language word order, formatting scope, variables, or export integrity. It does not replace a general guide to placeholders, file preparation, HTML, XML, localization engineering, or QA profiles. The focus is the inline decision inside the translator’s current segment.
Quick answer
When a source segment contains inline tags, translate quickly by using this sequence:
- identify what each tag actually controls;
- separate formatting tags from variables and non-translatable placeholders;
- translate the sentence for target-language meaning and word order;
- attach each opening-and-closing tag pair to the target span that performs the same function;
- copy tags with the CAT tool’s tag commands instead of typing technical syntax manually;
- verify paired tags, single tags, nesting, variables, numbers, and punctuation;
- run tag QA before export;
- inspect a rendered sample when formatting or layout matters.
The key idea is simple:
tags belong to functions, not positions.
If the source bolds the product name, the target should bold the translated or preserved product-name span—even if that span moves elsewhere in the sentence.
What an inline tag is
A CAT tool usually hides or simplifies technical markup so the translator can work with language rather than raw code.
A source file might contain markup like:
Click <b>Save</b> to continue.
The editor may show the bold markers as numbered tags:
Click [1]Save[2] to continue.
Or as compact paired symbols.
The exact display differs by platform.
The underlying job does not.
The opening marker begins a formatting or structural span.
The closing marker ends it.
The text between them carries the affected meaning.
The translator must preserve the relationship.
Formatting tags are not punctuation
This distinction matters because punctuation often stays near roughly the same visual position.
Tags often cannot.
Suppose the source says:
Select [1]Advanced settings[2] from the menu.
A target language may naturally say the equivalent of:
From the menu, select [1]Advanced settings[2].
The tagged phrase moved from the middle of the sentence to the end.
That is correct if the formatting function belongs to the phrase.
A mechanical translator who tries to keep every tag in the same character position will create unnatural language.
A careless translator who ignores the tags may create broken formatting.
The correct approach is semantic attachment.
Step 1: decide what the tag represents
Before moving a tag, ask what it does.
Common possibilities include:
- bold;
- italics;
- underline;
- superscript;
- subscript;
- hyperlink boundary;
- footnote anchor;
- cross-reference marker;
- character style;
- protected product string;
- XML element;
- inline code;
- image or object anchor;
- variable;
- placeholder;
- line break;
- nonbreaking element.
Different tag functions create different translation constraints.
A bold pair is usually movable.
A variable may need exact preservation.
A footnote anchor may need to remain next to a particular concept.
A line break may affect visible layout.
Treating all tags as identical gray boxes hides important information.
Step 2: learn the editor’s expanded-tag view
Most professional environments allow some form of expanded tag display.
Use it when the simplified view does not tell you enough.
An expanded tag may reveal:
- tag name;
- identifier;
- attribute;
- whether it opens or closes;
- whether it is paired;
- whether it represents formatting or a variable.
Do not keep expanded tags visible all day if they make reading harder.
Use the simple view for normal drafting.
Expand when you need to understand a risky segment.
That is a speed principle in itself:
show more technical detail only when the decision requires it.
Worked example 1: bold text moves
Source:
To continue, click [1]Create account[2].
Suppose the target language prefers the action first and the purpose second.
A natural target may place the equivalent of “Create account” earlier.
The safe procedure is:
- translate the sentence naturally;
- identify the target words meaning “Create account”;
- place the opening tag immediately before that span;
- place the closing tag immediately after it.
The tags follow the semantic span.
They do not preserve source coordinates.
Worked example 2: emphasis changes scope
Source:
Do [1]not[2] disconnect the cable.
The tag emphasizes only “not.”
A target language may express the prohibition through a negative verb form rather than a separate standalone word.
Now the translator must ask:
What target span carries the emphasized prohibition?
Perhaps the emphasized unit becomes part of the verb.
Perhaps the whole verb phrase should receive emphasis.
Perhaps the product style guide has a rule.
This is why tag placement is not purely technical.
The source markup can carry rhetorical meaning.
Step 3: distinguish tags from placeholders
Tags and placeholders may appear visually similar.
Their jobs differ.
A formatting tag often wraps target text.
A placeholder often stands for content supplied elsewhere.
Example:
Hello, {name}.
The {name} token may be replaced at runtime.
It should not be translated.
Its position may move if target grammar requires it, but its spelling and delimiters usually must remain exact.
Another source:
Your balance is {amount}.
The target language may put {amount} earlier.
Again, function matters.
Do not type a variable from memory when the CAT tool can insert it exactly.
One changed brace, percent sign, or positional index can break runtime output.
Step 4: use insertion commands, not manual recreation
Professional editors commonly provide methods to:
- copy the next tag;
- insert a specific tag;
- copy all source tags;
- select from available tags;
- insert a paired tag around selected target text.
Learn those commands.
The principle is broader than any vendor-specific shortcut:
reuse the source file’s structural tokens rather than recreating them.
This reduces:
- mistyped IDs;
- mismatched brackets;
- wrong closing tags;
- accidental deletion;
- wrong variable names.
Translation speed rises when technical tokens become insertion operations instead of typing operations.
Why typing tags manually is risky
Imagine the source contains:
<ph id="7"/>
The translator manually types:
<ph id="1"/>
It looks plausible.
It is wrong.
Or the source contains:
{0}
and the translator types:
{O}
zero becomes capital O.
The target text may appear normal in the CAT editor but fail later.
When a system provides a protected object for the tag, use it.
Step 5: draft the language before obsessing over tag micro-position
Tag-heavy segments can slow translators because the eye keeps jumping between markers.
A useful method is:
- understand the sentence;
- identify the tagged spans;
- mentally or temporarily translate the sentence;
- place tags once the target structure is clear.
Do not repeatedly move the same tag while still deciding basic syntax.
Solve language first, then structure.
The two steps may happen within seconds.
The order matters.
A tag-mapping note
For a difficult sentence, write a quick mapping:
- Tag 1–2 = product name
- Tag 3 = footnote anchor
- Tag 4–5 = warning phrase
Now translate.
Then attach the pairs.
This technique is especially useful when one source segment contains several nested or overlapping functions.
Nested tags
Nested formatting looks like:
[1]This is [2]very important[3].[4]
One pair may represent bold around the whole sentence.
Another pair may represent italics around “very important.”
The target must preserve the nesting hierarchy unless the file type and workflow explicitly permit another structure.
A common failure is crossing pairs:
Source nesting:
A opens → B opens → B closes → A closes.
Broken target:
A opens → B opens → A closes → B closes.
That can create invalid markup.
Visual simplification in the CAT editor may make the error easy to miss.
Tag QA exists partly for this reason.
A simple nesting rule
Think of paired tags like brackets:
A(B)A
not:
A(B A)B
The last tag opened is often the first tag that must close when structures are properly nested.
If you are unsure, compare source tag order carefully.
Single tags
Some tags are not paired.
They may represent:
- line break;
- image anchor;
- footnote marker;
- page break;
- joined-segment marker;
- special object.
Single tags need a target position.
That position should be controlled by function.
A footnote marker belongs near the content the footnote explains.
A line break may belong at a layout boundary.
An object marker may belong after the noun it illustrates.
Do not assume single tags can remain at the same ordinal word position.
Worked example 3: footnote marker
Source:
The warranty period is twenty-four months[1].
The tag is a footnote anchor after “months.”
If the target language reorders the phrase, keep the footnote attached to the proposition it qualifies.
Do not move the marker to the end of a different clause simply because the sentence became longer.
The right question is:
What does this note refer to?
Hyperlink tags
A hyperlink may wrap anchor text.
Source:
Read our [1]privacy policy[2].
The target may translate “privacy policy.”
The hyperlink tags should wrap the target words that function as the link.
If the target language expands the phrase, the whole clickable span may need to expand too.
But sometimes the source link target assumes a specific branded label.
Check the style guide and preview.
Hyperlink failure mode
A translator places the opening tag before the target phrase but closes it after the final punctuation.
Now the period becomes part of the link.
That may be acceptable in one style.
It may be undesirable in another.
The source gives evidence, but target typography and product conventions matter.
This is why preview is useful after structurally complex translation.
Tags and punctuation
Punctuation can move relative to tags between languages.
Examples:
- quote marks;
- commas;
- periods;
- colon;
- parentheses;
- dashes.
Do not force target punctuation inside or outside formatting solely because the source did so.
Determine:
- what is formatted;
- what belongs to the sentence;
- what the target style requires.
Then preserve valid tag structure.
Tags and word order
The more different the source and target word order, the more important semantic tag placement becomes.
Languages may reorder:
- adjective and noun;
- verb and object;
- relative clauses;
- possessors;
- particles;
- modifiers;
- negation.
If tags mark one source phrase, the corresponding target phrase may shift dramatically.
Fast translators stop thinking:
tag 1 was after word 4.
They think:
tag 1 begins emphasis on concept X.
That mental representation transfers across languages.
Tags and grammatical agreement
Suppose a tag wraps only the noun in the source.
In the target language, adjective agreement may make the adjective part of the meaningful emphasized unit.
Should the tag wrap noun only or adjective plus noun?
There is no universal answer.
Ask:
- what did the source author intend to emphasize?
- what span in the target carries equivalent emphasis?
- is the formatting semantic or merely stylistic?
- does the client style guide constrain it?
The tag may need a different surface span to preserve the same communication function.
Tags in machine translation output
Current CAT integrations can preserve source tags in machine-generated suggestions, but tag placement still needs human verification.
Machine translation may:
- keep all tags correctly;
- attach a tag to the wrong target word;
- shift emphasis;
- duplicate tags;
- change nesting;
- mishandle placeholders.
Do not assume a fluent MT sentence has technically correct structure.
Review language and tags as separate dimensions.
A two-pass tag review
For tag-heavy material, use two micro-passes.
Pass 1: meaning
Does the translation say the right thing naturally?
Pass 2: structure
Are tags, placeholders, variables, and formatting attached correctly?
This is often faster than trying to solve every layer simultaneously.
High-risk tag segments
Slow down slightly when a segment contains:
- many nested tags;
- multiple variables;
- mathematical notation;
- legal cross-references;
- hyperlinks;
- footnotes;
- HTML;
- XML;
- software placeholders;
- inline code;
- mixed right-to-left and left-to-right content.
A ten-second structural check can prevent a long export failure investigation.
Why tag errors become expensive late
An incorrect word is usually visible to a reviewer.
A broken tag may not become obvious until:
- export;
- compilation;
- file generation;
- website rendering;
- app runtime;
- desktop publishing.
Late defects have higher repair cost because the file has moved downstream.
So tag QA is not bureaucracy.
It is cheap prevention.
Failure mode 1: missing tag
The source contains opening and closing tags.
The target omits one.
Possible result:
- formatting disappears;
- export fails;
- formatting extends too far;
- technical validation fails.
Repair:
- use tag QA;
- compare tag count;
- restore the missing tag from source.
Failure mode 2: extra tag
The target contains a duplicated tag.
Possible result:
- invalid structure;
- duplicate placeholder;
- formatting error.
Repair:
- do not copy all tags repeatedly without checking;
- compare source and target tag inventory.
Failure mode 3: wrong tag order
All tags are present, but the order is invalid.
Repair:
- inspect pairs and nesting;
- compare expanded tag sequence;
- use editor validation.
Failure mode 4: right tags, wrong semantic span
Technically valid export.
Linguistically wrong emphasis.
This is especially dangerous because automated QA may not catch it.
Example:
source bolds do not.
target bolds an unrelated noun.
The file works.
The message changes.
Human semantic review is required.
Failure mode 5: tag stuck to source word order
The translator preserves source marker position and produces unnatural target syntax.
Repair:
- map tag to function;
- rewrite target naturally;
- relocate structural markers afterward.
Failure mode 6: placeholder translated
Source:
Welcome, {first_name}
Target contains a translated variable name.
Runtime cannot replace it.
Repair:
- use protected insertion;
- keep code tokens exact.
Failure mode 7: punctuation trapped inside wrong pair
The phrase remains correct, but punctuation or spaces inherit formatting unexpectedly.
Repair:
- inspect the rendered target;
- follow target-language typography and product conventions.
Failure mode 8: copied tags but missed changed source structure
A fuzzy match includes older tag structure.
The new source added or removed a formatting span.
Translator accepts the old target with old tags.
Repair:
- compare source diff;
- do not judge fuzzy matches on wording alone.
Tag QA should happen before export
A good project has at least one automated check for:
- missing tags;
- extra tags;
- tag order;
- placeholder mismatch;
- number mismatch;
- malformed inline structure.
Run it while the project is still easy to edit.
Waiting for export failure is slower.
But tag QA cannot judge emphasis
Automated checks are strongest at structural identity.
They can often detect:
- source has tag X, target does not;
- tag sequence is invalid;
- placeholder count differs.
They usually cannot know whether the bold span should wrap three words or five for equivalent rhetoric.
That remains a translation decision.
Automation checks form.
Humans check function.
A practical tag workflow for long technical files
Before translation
- inspect one representative file;
- expand tags in a few complex segments;
- learn what common tags mean;
- identify recurring variables;
- run a small round-trip export if file type is unfamiliar.
During translation
- draft meaning first;
- insert tags using tool commands;
- verify high-risk segments immediately;
- avoid manual code typing.
Before delivery
- run tag QA;
- inspect warnings;
- render or preview sample pages;
- verify links, footnotes, bold, italics, and variables.
This keeps technical friction controlled instead of scattered.
Tag density as a project signal
A file with two tags per hundred sentences is different from a file with eight tags per sentence.
High tag density predicts:
- slower visual reading;
- more cursor movement;
- higher technical risk;
- greater QA importance.
Project managers should treat tag density as part of workload, not as invisible punctuation.
A worked technical example
Source:
To change your [1]billing address[2], select [3]Account[4] > [5]Settings[6].
The sentence contains three paired spans.
The target language prefers:
Select [3]Account[4] > [5]Settings[6] to change the [1]billing address[2].
All content survives.
All tags survive.
The order of tag pairs changes because target syntax changed.
This is correct.
The CAT tool should care that pairs remain valid.
The translator should care that each pair still marks the correct function.
A worked variable example
Source:
{user} uploaded [1]{file_name}[2] at {time}.
The variables are runtime data.
The formatting pair wraps the filename.
A target language may place time first:
At {time}, {user} uploaded [1]{file_name}[2].
The variables moved.
Their identifiers did not change.
The filename remains formatted.
This illustrates the full principle:
- syntax is flexible;
- identifiers are stable;
- semantic relationships are preserved.
Tags in spreadsheets
Spreadsheet-derived translation can expose tags for:
- formulas;
- links;
- cell formatting;
- line breaks;
- embedded objects.
A translator should not assume gray tags are irrelevant metadata.
If the exported workbook must calculate correctly, structural preservation matters.
Use file-type-specific QA and a sample export.
Tags in XML and structured content
Structured formats can be stricter.
A single malformed inline element may prevent file generation or downstream import.
High-risk rules:
- never invent tag names;
- never change IDs unless instructed;
- never remove required pairs;
- never normalize technical syntax manually;
- never assume visible target text proves file validity.
The editor exists partly to protect you from raw XML.
Let it.
Tags in desktop-publishing files
IDML and other layout files may expose many inline markers.
Some formatting actions are supported differently across platforms.
The translator’s job remains to preserve meaning and structural markers, but final quality also depends on rendered layout.
Tag correctness is necessary.
It is not sufficient for desktop-publishing quality.
Tags in subtitles
Subtitle systems may contain style markers, speaker labels, line breaks, or timing-related syntax.
Moving a tag can affect:
- emphasis;
- readability;
- cue layout.
Keep audiovisual context in mind.
A technically valid target can still be a poor subtitle.
Tags in e-learning
E-learning localization commonly contains:
- HTML markup;
- variables;
- quiz tokens;
- interaction labels;
- links;
- SCORM-related structures.
Tag mistakes can break learning interactions.
Before a large course, test one export and re-import path.
This is faster than discovering systemic tag handling problems at the end.
Learning to read through tags
Beginners often read:
Click [1]the [2]blue[3] button[4].
as a broken sequence.
Experienced translators mentally suppress the tag noise and recover:
Click the blue button.
Then they restore formatting function.
You can train this.
Take tag-rich segments and practise reading only lexical content first.
Then map structure.
This reduces visual interference.
A simple tag-reading drill
Take twenty segments with tags.
For each one:
- read the plain sentence aloud;
- state what each tag does;
- translate without looking at tag positions;
- insert tags afterward;
- compare with source function.
Time the set.
Repeat a week later.
The goal is not faster clicking.
The goal is faster structural understanding.
Keyboard efficiency
If your editor has shortcuts for:
- next tag;
- copy source tag;
- insert tag pair;
- expand tag display;
- validate segment;
learn them.
But do not memorize twenty shortcuts at once.
Start with the two actions you repeat most.
Speed comes from eliminating frequent friction.
When to copy all tags at once
Copy-all can be efficient when:
- target structure is similar;
- tags are numerous;
- tag order is stable.
It can be counterproductive when:
- target word order differs greatly;
- tags need major movement;
- source contains many nested pairs.
Choose the operation based on structural similarity.
When to build target text between existing tags
Sometimes the fastest workflow is:
- copy source structure to target;
- replace source lexical content with target text;
- move tags if required.
This works well when:
- languages have similar order;
- tags are dense;
- source contains many protected tokens.
It works poorly when source syntax strongly interferes with target formulation.
There is no universal single best keystroke sequence.
There is a decision about which representation creates less cognitive friction.
Tag visibility and focus
Some editors let you simplify tag display.
Use the least noisy view that still protects correctness.
Possible routine:
- simple view during ordinary translation;
- expanded view for complex segments;
- QA list for structural verification.
This is another example of information control.
Too little detail creates errors.
Too much detail slows reading.
Tag mismatch warnings: fix or explain
When QA flags a mismatch, do not click “ignore” automatically.
Classify it.
Real error
Fix it.
Intentional difference allowed by file type
Document why.
False positive
Add the exception if the tool supports a safe rule.
Unknown
Investigate before delivery.
A warning has value only if the team understands its status.