How People Translate Quickly | Placeholders and Non-Translatables: Insert Numbers, Codes and Variables Without Retyping Them

People searching how to translate faster, CAT tool placeholders, non-translatables in translation, translation variables, numbers in CAT tools, or how to handle placeholders in localization are usually trying to solve a deceptively simple problem: much of a source segment is not ordinary prose. It may contain dates, product codes, variables, email addresses, serial numbers, URLs, measurements, tags, or values that must survive into the target without being manually retyped from memory.

Fast translators treat these elements as controlled placeables rather than as ordinary words. When the CAT environment can recognize a number, code, variable, placeholder, or other non-translatable element and insert it directly into the target, the translator saves keystrokes and reduces transcription errors at the same time. The speed gain is not merely typing faster. It is refusing to manually recreate information that the system can transfer more reliably.

This article explains how people translate quickly by handling placeholders and non-translatables with a disciplined workflow. The reader job is narrow: identify which source elements should be transferred, transformed, or preserved; insert them efficiently; place them in correct target-language order; and verify that automation has not mistaken a translatable element for a non-translatable one.

Quick answer

When a source segment contains numbers, variables, codes, URLs, placeholders, or protected elements, do not retype them unless the project requires transformation. Use the CAT tool’s insertion or placeholder mechanism where available. Then verify three things:

every required element is present;
each element appears in the correct target-language position;
its formatting and meaning are appropriate for the target locale.

The fast sequence is:

identify protected elements → classify transfer versus transform → insert → reorder if necessary → verify count and form → confirm

The central rule is:

copy structure automatically; interpret meaning deliberately.

What counts as a placeholder or non-translatable element

The exact terminology varies by tool and workflow.

Common examples include:

{name};
%s;
%1;
{{user_id}};
;
URLs;
email addresses;
serial numbers;
SKU codes;
product IDs;
file paths;
version numbers;
dates;
times;
measurements;
currency values;
telephone numbers;
mathematical symbols;
reference numbers.

Some elements must be copied exactly.

Some must be reformatted.

Some must be moved.

Some may look non-translatable but actually require localization.

That classification is the translator’s job.

Why manual retyping is slow

Suppose the source contains:

“Enter code AB-4279 before 14:30 on 05/10/2026.”

A translator who manually types every code, digit, hyphen, colon, and slash creates multiple opportunities for error.

Possible mistakes include:

AB-4729 instead of AB-4279;
14:03 instead of 14:30;
missing hyphen;
wrong date digit;
accidental localization of a protected product code.

Even when no error occurs, attention is spent checking visual strings rather than translating meaning.

Insertion tools shift that burden.

The three-way classification

Every special element should fall into one of three practical categories.

Copy exactly

Examples:

product codes;
serial numbers;
variables;
file extensions;
fixed identifiers;
many URLs;
placeholder tokens.

The target should preserve the source element unchanged unless instructions say otherwise.

Transform by locale

Examples:

date format;
decimal separator;
thousands separator;
currency presentation;
time format;
measurement unit where conversion is required.

The value or concept survives, but the surface form may change.

Translate or interpret

Examples:

textual parts inside a composite code;
human-readable URL slugs where localization is planned;
units whose names are written out;
placeholders accompanied by grammatical instructions;
abbreviations that are not actually protected identifiers.

Do not assume visual compactness means non-translatable.

The speed mechanism: reduce transcription

Translation already requires semantic decisions.

Retyping exact symbols adds low-value motor work.

Whenever the system can transfer a value reliably, let it.

This has two benefits:

fewer keystrokes;
fewer factual transcription errors.

The second benefit matters more.

A translation can be beautifully written and still fail because one serial number is wrong.

Worked example 1: a variable in a sentence

Source:

“Hello, {first_name}. Your order is ready.”

The variable {first_name} must remain intact.

The target language may place the name elsewhere.

A good workflow is:

translate the sentence structure;
insert the placeholder through the CAT mechanism;
move it to the natural target position;
verify braces, spelling, and identifier;
confirm.

Do not translate first_name inside the variable unless the software specification explicitly requires localized variable names.

The token belongs to the system, not the reader.

Worked example 2: multiple placeholders

Source:

“{user} uploaded {count} files to {folder}.”

The target language may require a different order.

The three placeholders are not simply copied left to right.

They are semantic roles:

actor;
quantity;
destination.

Insert all three, but position them according to target grammar.

This shows why placeholder handling is not clerical.

The symbols are protected.

Their sentence roles remain linguistic.

Worked example 3: a product code

Source:

“Install module XR-410B before startup.”

The code XR-410B is likely an identifier.

Copy it exactly.

Do not:

translate XR;
change hyphen style casually;
insert spaces;
alter capitalization;
convert digits.

If the code appears repeatedly, direct insertion reduces risk.

Worked example 4: a date

Source:

“The policy takes effect on 09/10/2026.”

This is not automatically a simple copy task.

Questions arise:

Is the source format month/day or day/month?
Does the target locale prefer a written month?
Is the project required to preserve the original legal date format?
Would transformation introduce ambiguity?

A date may be detected as a placeable while still requiring semantic verification.

Automation recognizes structure.

The translator resolves convention.

Worked example 5: decimal separators

Source:

“The tolerance is 0.75 mm.”

A target locale may use a comma decimal separator.

But the project may preserve SI formatting conventions or technical source style.

Do not mechanically transform every period or comma.

Use project instructions and domain standards.

The translator’s job is to distinguish locale formatting from scientific notation requirements.

Worked example 6: a URL

Source:

“Visit https://example.com/support for assistance.”

The URL may need to remain exactly as written.

Or the project may have a localized support URL.

Before copying, check whether:

locale-specific pages exist;
link targets are mapped;
URL localization is controlled elsewhere.

A CAT tool may correctly identify the URL as non-translatable while the project still expects a target-language destination.

“Non-translatable string” and “unchanged user experience” are not always the same thing.

Worked example 7: email addresses

Source:

“Contact billing@example.com.”

Email addresses normally remain unchanged.

Still verify:

no punctuation was accidentally included;
the address belongs to the correct locale or region;
line-breaking did not corrupt it;
the source itself is correct.

Insertion protects spelling.

It does not validate business logic.

Worked example 8: currency

Source:

“The service costs $1,250.00.”

Possible target requirements include:

currency code instead of symbol;
localized separators;
symbol before or after amount;
currency conversion;
no conversion at all.

The CAT tool may detect the number and currency.

The translation brief decides what transformation is authorized.

Never convert monetary value merely because localization feels natural.

Financial content requires explicit rules.

Worked example 9: measurements

Source:

“Maintain a clearance of 12 in.”

Should the target say:

12 in;
12 inches translated;
30.48 cm;
approximately 30 cm?

These are not equivalent editorial choices.

Unit conversion can introduce rounding, regulatory, or technical consequences.

Treat measurement handling as a project rule.

A fast translator follows an established unit policy rather than re-deciding each measurement.

Placeholders versus tags

Placeholders and tags are related but not identical.

A placeholder often represents dynamic content that will be inserted at runtime.

A tag may preserve formatting, markup, a link, or document structure.

Examples:

Placeholder:

{username}

Tag:

 ... 

Both may appear as protected elements in a CAT editor.

Both can break output if mishandled.

But their semantic roles differ.

Understanding the distinction helps with placement.

Paired tags and word order

Consider source markup:

“Click Submit to continue.”

If the target reorders the sentence, the paired tags must still surround the target equivalent of “Submit,” not merely occupy their original linear positions.

This is a classic example of why tag transfer is not blind copying.

Preserve the relationship:

opening tag → intended target span → closing tag

Target syntax may move the whole tagged span.

Placeholder order can differ from source order

Source:

“{count} messages were sent by {user}.”

A target language may naturally say:

“{user} sent {count} messages.”

The variable order changes.

This is correct if the software supports positional placeholders that can move independently.

But some formatting systems use ordered variables such as %1, %2, or %s with specific runtime expectations.

Know the placeholder model.

A linguistically natural reorder can still break software if the technical syntax does not permit it.

Numbered placeholders

Numbered placeholders often encode argument identity.

For example:

“%1 invited %2.”

If the target reorders the participants, %1 and %2 must follow their semantic roles.

Never replace %1 with %2 merely because the target word order changes.

The number is not a sequence instruction unless the system defines it that way.

It is often an identifier.

Repeated placeholder names

Source:

“{name}, update {name}’s profile.”

The same placeholder appears twice.

The target may not require two identical surface insertions if possession or pronoun rules differ, but the runtime system will insert the same value in both places.

This can reveal localization limitations.

If the dynamic content cannot inflect appropriately in the target language, the translator may need a product-language redesign rather than a clever sentence.

Flag the issue.

Do not disguise it.

Plural-sensitive variables

Source:

“You have {count} new messages.”

The sentence looks simple.

Many languages require plural forms depending on the numerical value.

A placeholder-aware translation may need:

plural categories;
message-format syntax;
separate strings;
grammatical gender handling.

Do not treat {count} as a harmless number copied into one universal sentence.

The runtime value can control grammar.

Gender-sensitive variables

Source:

“{user} updated their profile.”

The source may avoid gender.

The target language may force agreement.

If {user} supplies only a name and no grammatical-gender feature, the sentence may need restructuring to avoid unstable agreement.

This is not solved by inserting the placeholder faster.

It is a localization design issue.

Fast translators recognize when a placeable creates a grammar dependency the source system has not modeled.

Non-translatable detection can be wrong

Automated systems may classify an element as non-translatable because it looks like:

code;
identifier;
proper name;
number-only segment;
URL;
acronym.

But appearances can mislead.

A source string such as:

“HOME”

might be:

a navigation label that needs translation;
a product code that must remain;
a key name;
an acronym;
a literal English word inside a design.

Do not accept non-translatable status without context when the string is reader-facing.

Worked example 10: acronym or code?

Source:

“Enter PIN.”

In many contexts, PIN is a conventional acronym.

In another product, PIN could be an internal feature code.

The target market may commonly use PIN unchanged, or may require an established local term.

The correct decision depends on domain and audience.

A non-translatable candidate still requires concept recognition.

Use insert commands instead of typing

Most CAT environments provide ways to insert tags, placeholders, matches, numbers, or other recognized elements without manual retyping.

The exact commands vary.

The productivity principle is stable:

transfer by reference rather than recreate by hand.

Learn the native method in the tool you use.

The best insertion workflow keeps attention inside the segment.

Placeables and keyboard rhythm

Fast translation depends partly on maintaining a stable motor sequence.

If every placeholder forces the translator to reach for the mouse, search visually, and click a tiny token, attention fragments.

Where the tool supports reliable shortcuts or sequential tag insertion, learn them.

But do not memorize dozens of commands at once.

Start with high-frequency actions:

insert next tag;
insert specific placeholder;
confirm segment;
jump to next unresolved issue.

Tool fluency matters when it reduces context switching.

Do not over-automate locale transformation

Some tools can automatically format numbers, dates, or units.

Automation is useful when the rule is stable.

It is risky when:

source date format is ambiguous;
currencies must not be converted;
technical standards preserve source notation;
product codes contain digit groups that resemble numbers;
version numbers look like decimals.

Use automatic transformation only for well-defined classes.

A value that looks numeric may not behave like a number.

Version numbers

Source:

“Version 3.10”

Do not convert this to “3,10” merely because the target locale uses decimal commas.

A version number is an identifier, not necessarily a decimal value.

This is a classic category error.

The translator must classify the token before applying locale rules.

IP addresses and network identifiers

Source:

“Connect to 192.168.1.10.”

The dots are structural.

They are not decimal separators.

Do not localize them.

The same applies to:

domain names;
MAC addresses;
hashes;
UUIDs;
API keys.

Protected technical identifiers require exact preservation.

File paths

Source:

C:\Program Files\App\config

A localized operating system may display folder names differently, but changing a literal path can make an instruction unusable.

Determine whether the string is:

literal machine path;
illustrative example;
user-visible translated label.

Technical strings require functional interpretation.

Command-line examples

Source:

app --lang=en --output=file.txt

The command itself may be non-translatable.

Explanatory comments around it may need translation.

Never translate parameter names unless the software defines localized commands.

A CAT workflow should protect code while exposing prose.

If code is not protected automatically, use project rules rather than improvisation.

Serial numbers and reference IDs

Reference strings are easy to mistype because they lack semantic redundancy.

If you mistype “temperature,” spellcheck may catch it.

If you mistype K7B-91Q4, no linguistic intuition helps.

This is exactly the kind of element that should be copied or inserted mechanically.

The stranger the identifier, the stronger the case against retyping.

Telephone numbers

Phone numbers may require:

international dialing prefix;
spacing convention;
locale-specific support number;
unchanged source number.

A non-translatable detector may preserve the digits perfectly while still delivering the wrong customer-service route for the target market.

Always distinguish transcription from localization logic.

Time expressions

Source:

“The service closes at 5:30 PM.”

The target may use:

17:30;
5.30;
localized AM/PM notation;
time-zone clarification.

Again, the underlying time and the display format are separate.

Automated insertion protects the value.

Locale rules control presentation.

Dates with month names

Source:

“18 September 2026”

The month word is translatable.

The digits may be transferable.

The order may change.

Some CAT tools treat the date as one structured placeable, others as normal text.

Regardless of implementation, the translator should preserve the actual date while rendering it according to authorized conventions.

Numbers inside prose

Source:

“Three users failed the test.”

The number is written as a word.

It is not a protected numeric token.

It may interact with target grammar differently from the numeral “3.”

Do not assume all quantitative information is handled by placeable logic.

Recognize the semantic category even when the surface form changes.

Placeholders in right-to-left languages

Bidirectional text can make placeholders, numbers, punctuation, and Latin-script variables visually confusing.

The token may appear to jump around on screen.

Verify logical order, not only visual impression.

Use platform preview where available.

Do not manually add invisible directional characters unless the workflow explicitly requires them and you understand the effect.

RTL handling is a system-level concern.

Placeholders in subtitles

Subtitle formats can contain:

timecodes;
speaker markers;
formatting tags;
position tags.

These elements must often be preserved exactly while dialogue is translated.

A transcription error in timing markup can damage playback.

Treat technical subtitle structure separately from dialogue language.

Placeholders in e-learning

E-learning packages may contain:

variable names;
quiz scoring tokens;
LMS placeholders;
interaction labels;
HTML tags;
accessibility metadata.

Do not assume every visible token is learner-facing.

Translation speed improves when structural code is protected before linguistic work begins.

If the file exposes too much code as editable text, that may be a file-preparation problem.

Placeholders in templates

Document templates often contain fields such as:

[CLIENT_NAME] [DATE] [ADDRESS]

Sometimes these markers should remain because another system fills them later.

Sometimes the final translated document expects localized labels.

Project instructions decide.

The translator should never remove a field marker just because it looks awkward in the target.

Build a protected-element inventory

For complex projects, create a tiny list of recurring protected element types.

For example:

product codes — copy exactly;
URLs — use localized destination table;
dates — day-month-year;
decimals — comma separator;
measurements — no conversion;
variables — preserve token exactly;
HTML tags — preserve structure;
phone numbers — replace with locale number from reference sheet.

This turns dozens of micro-decisions into a stable project policy.

Speed comes from not deciding the same category repeatedly.

Failure mode 1: manually retyping identifiers

This creates unnecessary risk.

Fix: insert or copy through the controlled tool mechanism.

Then verify once.

Failure mode 2: translating inside a placeholder

The translator changes {customer_name} to a target-language variable name.

The software expects the original key.

The string breaks.

Fix: distinguish machine-readable token from surrounding reader-facing prose.

Failure mode 3: preserving a user-facing string as non-translatable

A tool flags an uppercase word as protected.

The translator leaves it in English.

Users see untranslated UI.

Fix: confirm function before accepting non-translatable classification.

Failure mode 4: changing placeholder identity while reordering

The target sentence moves %1 and %2, but the translator accidentally swaps which participant each represents.

The sentence becomes logically wrong.

Fix: track semantic roles, not visual order.

Failure mode 5: dropping one placeholder

A source contains three variables.

The target contains two.

The software may catch this with QA, but do not depend solely on QA.

Count required placeholders before confirmation.

Failure mode 6: duplicating a placeholder

The target repeats {count} twice accidentally.

Runtime output becomes strange.

Again, compare source and target token counts.

Failure mode 7: localizing version numbers

A version string such as 2.5 is converted to 2,5.

The application or documentation reference no longer matches the product.

Classify identifier versus numeric value.

Failure mode 8: preserving an ambiguous date format

The source date 04/05/2026 is copied unchanged into a target locale where readers interpret it differently.

Copying perfectly can still communicate incorrectly.

Disambiguate authorized date presentation.

Failure mode 9: unit conversion without authority

A translator converts miles to kilometres or Fahrenheit to Celsius because the target audience uses metric units.

The conversion may be helpful.

It may also violate a technical, legal, or product requirement.

Follow project policy.

Failure mode 10: broken tag order

All tags are present, so the segment passes a simple count check.

But the opening and closing tags surround the wrong words.

Count is necessary.

Structural relation also matters.

The placeholder-count check

Before confirming a complex segment:

count source placeholders or tags;
count target placeholders or tags;
ensure identities match;
ensure paired tags are nested correctly;
ensure order follows target grammar and technical rules.

This takes seconds.

It catches a large class of avoidable defects.

The transfer-versus-transform check

For each special element, ask:

Does this survive unchanged, or does it require locale transformation?

Do not decide by appearance.

Use category and project rules.

A serial number survives.

A date may transform.

A currency value may need a display change but not conversion.

A URL may need a localized destination.

The reader-versus-system check

Ask:

Is this token meant for the human reader or for the software system?

Examples:

Human-facing:

visible date;
price;
unit label;
navigation word.

System-facing:

variable key;
API parameter;
markup tag;
product identifier.

Some tokens serve both.

The answer guides whether language localization is appropriate.

The exactness check

For protected identifiers, compare character by character where necessary.

Pay attention to:

O versus 0;
I versus l versus 1;
hyphen versus en dash;
underscore;
slash direction;
capitalization;
leading zeros.

Insertion tools are valuable because these distinctions are hard to proofread manually.

Use QA as a net, not a steering wheel

Automated QA can catch:

missing numbers;
missing tags;
altered placeholders;
inconsistent punctuation;
mismatched variables.

Use it.

But QA does not always know whether:

a date format is culturally ambiguous;
a URL should be localized;
a version number should stay unchanged;
a non-translatable label was incorrectly protected.

Human classification comes first.

QA checks execution.

Filter special-element segments for final review

A useful final pass can isolate segments containing:

numbers;
variables;
tags;
URLs;
email addresses;
units;
currency.

This creates a focused factual-integrity queue.

The reviewer is not judging style deeply.

The reviewer is asking:

Did every machine-readable or factual element survive correctly?

That is an efficient specialized pass.

Avoid mixing factual QA with stylistic revision

If you are checking placeholders, do not simultaneously rewrite every awkward sentence.

Mode switching slows review and increases the chance of missing structural tokens.

Use separate passes when the project justifies them:

semantic translation;
terminology;
special-element integrity;
final fluency.

This is especially helpful in code-heavy or data-heavy localization.

Worked example 11: order confirmation message

Source:

“Order {order_id} for {amount} will ship on {date}.”

Target language prefers:

“On {date}, order {order_id} worth {amount} will ship.”

All three variables survive.

Their order changes.

A successful translation preserves:

identity;
grammar;
runtime syntax;
meaning.

This is the essence of placeholder-aware translation.

Worked example 12: support ticket

Source:

“Ticket #A-10482 was updated by {agent_name} at 16:45.”

Potential concerns:

ticket identifier exactness;
variable integrity;
time localization;
sentence order.

The translator can insert the ticket ID and placeholder directly, transform time if authorized, and arrange the target naturally.

The protected elements reduce typing.

They do not remove linguistic decisions.

Worked example 13: software error

Source:

“File {filename} could not be saved to {path}.”

The target may reorder the path and filename.

But both placeholders must retain identity.

Do not translate {filename} or {path}.

If the runtime system inserts raw file paths using Latin characters, check how the sentence behaves around bidirectional text in RTL languages.

Technical tokens can influence typography.

Worked example 14: financial statement

Source:

“Balance: USD 12,450.75”

The organization may require:

currency code preserved;
amount unchanged;
localized separators;
accounting format;
no conversion.

The translator should not infer the rule from general consumer localization.

Financial documentation often has controlled presentation requirements.

Worked example 15: dosage-like measurement

Source:

“Add 2.5 mL.”

A decimal error is high consequence.

If the target uses decimal comma, approved transformation may produce 2,5 mL.

But spacing, decimal notation, and unit symbol may follow scientific or medical style rules.

Do not rely on casual locale intuition in high-stakes domains.

Use authoritative project standards.

Placeholders and machine translation

Machine translation systems may preserve placeholders well, badly, or inconsistently depending on preprocessing.

Possible failures include:

placeholder moved incorrectly;
placeholder duplicated;
placeholder omitted;
placeholder content altered;
punctuation attached incorrectly.

Even fluent machine output requires token verification.

A placeholder is a functional dependency.

Fluency does not prove structural integrity.

Placeholders and translation memory

A TM match may contain an older placeholder pattern.

New source:

“Hello {first_name}.”

Old TM:

“Hello {user_name}.”

The sentence is semantically similar.

The variable is not identical.

Do not import the old token by accident.

When fuzzy matches include placeholders, compare token identity explicitly.

The changed placeholder may be the most important delta.

Placeables and fuzzy matching

Numbers, tags, and placeholders can influence match scores differently across tools.

Do not assume a high match means all factual tokens match.

Compare them.

If the source changed only a number, the match may be extremely high.

That makes factual checking more important, not less.

Placeables and repetitions

Repeated segments containing variables may appear textually identical.

But runtime values will differ.

Usually this is fine if the sentence grammar works for all possible values.

But plural, gender, and case can make one static sentence unsafe.

Repeated template strings need grammar testing across value classes.

Build test values for dynamic strings

For important software strings, test more than one runtime value.

For {count}, test:

0;
1;
2;
larger number.

For {name}, test:

short name;
long name;
relevant scripts;
names that interact with punctuation.

For {amount}, test:

integer;
decimal;
large value.

This reveals grammatical and layout problems before release.

Student version: copy facts, translate language

Students can practice the same distinction in ordinary translation.

Take a sentence containing:

name;
date;
number;
unit;
reference code.

Mark which elements carry fixed factual identity and which require linguistic translation.

This reduces accidental number and name errors in school translation exercises.

Transfer: data entry

The principle extends beyond translation.

When a system can copy an identifier reliably, do not retype it.

Human transcription of arbitrary strings is error-prone.

Transfer: coding

Developers preserve variable names and syntax while changing surrounding comments or user-facing strings.

The same boundary exists:

system tokens follow machine rules;

reader-facing language follows linguistic rules.

Transfer: document production

Templates, mail merges, forms, and reports all combine static language with dynamic fields.

Writers who understand field boundaries produce more reliable documents.

Translation is one instance of a broader structured-content problem.

A thirty-second placeholder routine

For any segment with protected elements:

identify every token;
decide copy, transform, or translate;
insert rather than retype;
arrange tokens according to target grammar;
verify identities and counts;
check locale formatting where authorized;
reread the complete sentence;
run QA.

This routine is fast because it separates structural handling from linguistic phrasing.

A pre-delivery special-element checklist

Before delivery, confirm:

no placeholder missing;
no placeholder duplicated;
variable names unchanged where required;
tags paired correctly;
numbers accurate;
dates unambiguous;
times correct;
currency treatment authorized;
unit handling consistent;
URLs and email addresses valid;
product codes unchanged;
version numbers not localized accidentally;
file paths intact;
target grammar works around inserted tokens.

The checklist is especially valuable in software, technical, financial, and templated content.

The deeper principle: do not spend human attention on copying what machines can copy exactly

Translation is expensive because meaning requires judgment.

Identifiers, variables, and protected structures often do not.

Let the system handle exact transfer where it is reliable.

Reserve human attention for:

classification;
grammar;
locale conventions;
functional meaning;
exceptions.

That is the correct division of labor.

Placeholders and punctuation attachment

Placeholders often sit beside punctuation:

“Hello, {name}!”

The comma and exclamation mark belong to the reader-facing sentence, not to the placeholder itself.

If the target language uses different punctuation spacing or sentence structure, keep the token intact while moving the punctuation according to target convention.

Be careful when copying tokens with adjacent punctuation. Selecting {name}, as though the comma were part of the variable can produce duplicated or misplaced punctuation.

The safe unit is the placeholder identity.

Punctuation remains language.

Placeholders inside links

A link may contain both machine structure and dynamic values:

https://example.com/order/{order_id}

The domain, path, braces, and variable may all need exact preservation.

But the visible anchor text surrounding the link may require translation:

“View order {order_id}.”

Treat URL destination and user-facing label as separate layers.

A translator can preserve the technical link perfectly while still mistranslating the label, or translate the label beautifully while corrupting the destination.

Structured content requires layer awareness.

Non-translatables and proper names

Proper names are not automatically non-translatable.

A person’s name may require:

transliteration;
established target-script spelling;
order adjustment;
diacritics;
grammatical inflection.

A place name may have an established exonym.

An institution may have an official translated name.

A brand may require exact preservation.

Therefore “proper name” is a category that triggers verification, not a universal copy rule.

If the CAT system protects a name, confirm that project policy agrees.

Numbers that carry grammar

A numeric token can control surrounding grammar.

For example, the target equivalent of:

“{count} file(s) remaining”

may require several plural categories.

The number itself can be inserted correctly while the sentence remains grammatically wrong for certain runtime values.

This is why placeholder integrity and linguistic correctness are separate tests.

The token may be perfect.

The template may still be broken.

Placeholder-safe reviewer edits

Reviewers sometimes rewrite a sentence around variables.

Before accepting the edit, verify that the reviewer did not:

delete a token;
duplicate a token;
change token spelling;
swap identities;
move a paired tag incorrectly.

Review fluency and structure together.

A polished revision that breaks runtime substitution is worse than an awkward sentence that still functions.

Create a token-risk hierarchy

Not all protected elements deserve equal scrutiny.

High risk:

dosage-like numbers;
financial values;
legal dates;
security codes;
URLs used for user action;
variables controlling grammar.

Medium risk:

ordinary dates;
product identifiers;
version numbers;
phone numbers.

Lower risk:

repeated formatting tags whose structure is already stable.

This hierarchy helps allocate review attention.

The principle is the same throughout fast translation: spend the most human attention where a small token can create the largest consequence.

Advanced practice: classify protected tokens before translation starts

Placeholders and non-translatables become faster to handle when the project distinguishes their roles before drafting begins. A useful classification is:

identity tokens — product codes, model numbers, account IDs;
runtime variables — {first_name}, %s, {{user_id}};
technical syntax — HTML tags, ICU markers, command names;
fixed brand forms — approved names that must remain unchanged;
transformable data — dates, numbers, units, and currency values that may need locale-specific formatting.

The last category is especially important. A number can look non-translatable while still requiring transformation. For example, decimal separators, date order, thousands separators, and unit notation may differ by locale. Protect the underlying value while applying the project’s formatting rule.

Build a token-verification pass around exact identity

For runtime variables and codes, the fastest QA question is not “Does this look similar?” It is “Is the identity exactly preserved?”

Check:

spelling;
capitalization where significant;
braces, percent signs, angle brackets, or other delimiters;
order of positional placeholders;
duplicates and omissions;
whether surrounding spaces or punctuation belong inside or outside the token.

This is a strong candidate for automation because the acceptable form is often exact.

Use protected-token context to avoid grammatical damage

A placeholder may stay unchanged while the target grammar around it changes. For example, a variable inserted into a noun phrase may require a different preposition or article in the target language. Do not preserve the source sentence merely because the token itself is fixed.

The rule is:

protect the token; translate the relationship.

That keeps software integrity and natural target language compatible instead of treating them as competing goals.

Summary

Placeholders and non-translatables speed translation when the translator stops manually recreating numbers, codes, variables, tags, and other structured elements that can be inserted or transferred safely.

The method is not blind copying.

Classify each element as copy exactly, transform by locale, or translate/interpret. Insert protected tokens using the CAT workflow where available. Reorder them according to target grammar without changing identity. Verify counts, formatting, runtime logic, and high-risk values before confirmation.

The practical rule is:

automate exact transfer; apply human judgment to meaning and locale.

Frequently asked questions

What is a placeholder in translation?

A placeholder is a token representing dynamic content, such as {name}, %1, or {{user_id}}, which a system replaces with a value at runtime.

What is a non-translatable element?

It is an element intended to remain unchanged or structurally protected, such as certain codes, identifiers, URLs, variables, or technical tokens. Automated detection can still be wrong.

Should numbers always be copied exactly?

No. The value may remain the same while formatting changes by locale. High-stakes domains may require specific conventions.

Can placeholders be moved in the target sentence?

Often yes, when target grammar requires reordering, but placeholder identity and the technical syntax must remain valid.

Should variable names be translated?

Usually no. Machine-readable variable keys normally remain exact unless the software specification explicitly says otherwise.

Are dates placeables?

They may be recognized as structured values, but their display format can require localization and disambiguation.

What is the biggest placeholder mistake?

Changing, dropping, duplicating, or misidentifying a placeholder while producing otherwise fluent target text.

Why use insertion tools instead of typing?

They reduce keystrokes and, more importantly, reduce transcription errors in arbitrary strings such as codes and identifiers.

Can automated QA catch all placeholder problems?

No. QA can detect many missing or altered tokens but may not know whether a URL should be localized, a date is ambiguous, or a user-facing word was wrongly protected.

How should I review placeholder-heavy translation?

Use a dedicated factual-integrity pass that checks token identity, count, order, formatting, numbers, dates, units, and runtime grammar.

Internal-link opportunities

Natural internal links can connect this article to:

How People Translate Quickly | Tool Fluency: Keyboard Shortcuts, Search and CAT Navigation Without Breaking Focus — for efficient insertion and navigation.
How People Translate Quickly | Fuzzy Match Diffing: Repair What Changed Instead of Retranslating the Whole Segment — for matches where numbers, tags, or placeholders changed.
How People Translate Quickly | Repetition Auto-Propagation: Translate Repeated Segments Once Without Spreading the Wrong Context — for repeated template strings containing variables.
How People Translate Quickly | Segment Filtering: Hide Finished Work and Translate Only the Queue That Still Needs You — for building a numbers/placeholders review queue.
How People Translate Quickly | Safe Find and Replace: Fix Repeated Translation Errors in Bulk Without Creating New Ones — for structured corrections that must protect variables and codes.
Translate Like a Pro | Prepare Files for Translation Without Breaking Variables, Tags or Layout — for the upstream file-preparation perspective.