How People Translate Quickly | Source–Target Identity QA: Find Untranslated Same-as-Source Segments Without Flagging Brands, Codes or Proper Names

People searching identical source and target translation, same as source QA, untranslated segment check, original string equals target string, CAT tool untranslated check, or find source text left in translation are trying to catch one of the simplest-looking and most embarrassing release defects: the target is still the source. Current localization QA systems use language such as Original string equals target string, identical source and target, and untranslated same-as-source check because the mechanism is straightforward: compare the source value with the target value and flag segments that remain unchanged.

The hard part is not detecting equality. The hard part is deciding when equality is a mistake. A brand name may correctly remain unchanged. So may a product code, URL, chemical symbol, command name, model number, proper noun, file extension, or internationally shared technical abbreviation. A good source–target identity QA workflow therefore does not blindly reject every identical pair. It creates a focused review queue that separates missed translation from intentional preservation.

This article has one dominant reader job: use same-as-source QA to find genuinely untranslated target segments quickly, while building reliable exceptions for content that should remain identical. It does not replace translation completeness checks, glossary rules, target-language detection, placeholder QA, or non-translatable handling. Its job is narrower: when source and target are textually the same, decide whether that is correct, and make the decision reusable.

Quick answer

A practical same-as-source workflow is:

1. run an Original string equals target string or identical source and target quality check across translated content;
2. sort the findings by likely risk rather than reviewing them randomly;
3. immediately distinguish full natural-language sentences from obvious codes, names, URLs, variables, and non-translatables;
4. check whether the segment was intentionally copied, prefilled, locked, or confirmed;
5. use context, string key, screenshot, and project terminology to decide whether identical text is legitimate;
6. create controlled exceptions for stable do-not-translate content;
7. repair genuinely missed translations;
8. re-run the check after reviewer edits, imports, and bulk operations;
9. keep high-risk identical natural-language strings visible even if short;
10. finish with a final same-as-source sweep before delivery.

The key principle is:

identical text is a signal, not a verdict.

Why this check matters

A missing translation can survive surprisingly far through a workflow.

Imagine a 12,000-string software project. Most strings are translated. One English button label remains:

Delete account

The interface builds successfully.

The JSON is valid.

The placeholders are correct.

The app opens.

The untranslated action appears on the final screen.

Nothing “breaks” technically.

The defect is linguistic completeness.

This is exactly the kind of issue same-as-source checks are designed to surface.

The mechanism is simple

At its simplest, the QA engine compares:

source == target

or a normalized version such as:

trim(source) == trim(target)

If true, the segment becomes a review candidate.

Some localization checkers compare matching keys or XLIFF units. CAT tools may run the check when a segment is saved, confirmed, or included in a quality report.

The implementation can be simple.

The interpretation cannot.

Same-as-source is strongest when the languages differ visibly

English source → Japanese target.

If the target contains a full English sentence identical to source, that is suspicious.

English source → French target.

Also suspicious, although English loanwords and product labels may legitimately remain.

English source → English locale adaptation.

Much weaker signal, because source and target may intentionally match.

Therefore the value of the check depends partly on language pair.

Step 1: classify identical findings before editing

A useful first-pass classification is:

Class A: likely missed translation

Full sentence or ordinary phrase that normally should change.

Examples:

• Delete account
• Payment failed
• Contact your administrator
• Continue to checkout

Class B: likely intentional unchanged content

Examples:

• OpenAI
• USB-C
• ISO 9001
• X500
• example.com
• .json

Class C: context-dependent

Examples:

• Home
• Pro
• Premium
• Live
• Plus
• Standard

These may be product names, menu labels, or translatable words.

Class C deserves context.

Why full sentences deserve priority

An identical 14-word source sentence in a different-language target is far more likely to be a missed translation than the identical token USB.

When a report contains many findings, prioritize:

1. longer natural-language segments;
2. user-facing actions;
3. warnings and safety text;
4. legal or consent text;
5. ordinary headings;
6. short ambiguous labels;
7. obvious codes and identifiers.

Length is not proof.

It is useful triage.

Worked example 1: a real missed translation

Source:

Your password has expired. Create a new password to continue.

Target:

Your password has expired. Create a new password to continue.

Target locale:

German.

Unless the product deliberately uses English for this message, this is almost certainly untranslated.

Repair:

• translate;
• verify terminology for “password” and “continue”;
• confirm;
• rerun QA.

Worked example 2: a legitimate identical brand

Source:

Smartcat

Target:

Smartcat

The product name remains identical.

Do not “fix” it.

Instead, ensure the project knows this is a do-not-translate item so the same warning does not consume attention repeatedly.

Worked example 3: a dangerous short string

Source:

Save

Target:

Save

Target locale:

French.

Could it be a brand?

Could it be a command?

String key:

button.settings.save

Now the context makes the answer clear.

It should be translated.

Shortness should not lower attention when the string is a user action.

Step 2: use context keys and metadata

Localization files often carry identifiers such as:

• button.save
• status.open
• brand.name
• payment.retry
• nav.home

These keys are extremely useful in same-as-source review.

Source:

Home

Target:

Home

Key:

brand.product_tier.home

May be a branded product tier.

Key:

nav.home

Likely navigation label.

The visible text is identical.

The underlying function differs.

Use the metadata.

Step 3: distinguish do-not-translate from simply-not-translated

This sounds obvious, but it is the core governance issue.

Do-not-translate

The project has decided the source token should stay unchanged.

Examples:

• brand name;
• API method;
• command;
• registered product;
• file extension.

Not translated

Nobody completed the target language.

These states can look identical on screen.

A mature project records the difference.

Use termbases for stable do-not-translate items

If a product name must stay unchanged everywhere, make it a formal terminology rule where the system supports it.

Advantages:

• translator sees the rule;
• glossary compliance can recognize it;
• same-as-source warnings can be interpreted faster;
• future projects inherit the decision.

Do not rely on individual memory.

Non-translatable detection can reduce noise

Some CAT tools recognize structured non-translatables such as:

• URLs;
• email addresses;
• numbers;
• codes;
• variables.

If the system can classify them safely, same-as-source QA should avoid treating every one as a linguistic defect.

But do not overexpand the non-translatable list.

An ordinary word accidentally classified as protected can hide a missed translation.

Step 4: watch copied-source drafting habits

Some translators copy source into target as a drafting aid.

That can be efficient in certain language pairs or file types.

It is also risky.

If the translator is interrupted after copying but before translating, the target cell looks “filled.”

A completeness check based only on non-empty target will pass.

Same-as-source QA catches the unfinished state.

Copied-source targets need status discipline

If source text is copied temporarily:

• leave segment unconfirmed;
• mark it clearly;
• use identical-source QA;
• do not write it into TM as approved target.

Temporary scaffolding should not become reusable memory.

Step 5: watch pre-translation and import behavior

A project may import:

• legacy targets;
• machine translation;
• bilingual files;
• exact matches.

Sometimes an import pipeline copies source into target when no translation exists.

That is convenient for file structure.

It can hide completeness gaps.

After import, run same-as-source QA before assuming the target set is translated.

Empty target and identical target are different defects

Empty target

No target content.

Identical target

Target content exists but may still be untranslated.

A robust completeness check looks for both.

Do not treat “non-empty” as “translated.”

Step 6: protect correct same-language content

Projects sometimes adapt content within the same language:

• en-US → en-GB;
• pt-BR → pt-PT;
• zh-Hans → zh-Hant;
• regional legal variants.

Many segments may legitimately remain identical.

A blanket identical-source warning can become noisy.

Use a stronger review strategy:

• focus on strings containing known regional differences;
• use locale-specific terminology;
• compare spelling;
• check dates, currencies, punctuation, legal terms.

Same-as-source QA is less discriminating when source and target languages are near-identical.

Same-language adaptation needs different expectations

If 80% of content should remain unchanged, same-as-source warnings are not high-value by default.

Instead, configure:

• exception patterns;
• scope filters;
• locale change rules.

QA should fit the project.

Step 7: proper names need context

Names can remain unchanged:

• Ada Lovelace
• Singapore
• GitHub

But some names have established target-language forms:

• country names;
• institutions;
• historical figures;
• geographic names.

Do not assume every proper noun remains source-identical.

Use project policy and authoritative references.

Transliteration complicates identity

A source name in Cyrillic may be transliterated into Latin script.

A Japanese name may have approved romanization.

A Chinese institution may have official English name.

The target may need change even though it is “a name.”

Do-not-translate is not universal.

Step 8: product tiers and feature names

Strings such as:

• Pro
• Plus
• Premium
• Standard
• Studio
• Cloud

can be ordinary words or protected product labels.

Same-as-source QA should force a quick ownership question:

Is this lexical content or product identity?

Reference files and termbase answer it.

Step 9: codes and model numbers

Examples:

• X500
• AB-217
• ISO 13485
• v4.8.2
• SKU-00931

These are often intentionally unchanged.

But do not assume every alphanumeric string is untouchable.

Sometimes:

• suffix contains language code;
• decimal punctuation changes;
• code is descriptive rather than identifier.

Identity rules belong to the project.

Step 10: URLs and email addresses

URLs normally stay exact or follow localization routing rules.

Email addresses normally stay exact unless localized aliases are supplied.

If same-as-source QA flags them, classify them as technical non-translatables rather than dismissing the whole check.

A high-noise report can be improved by excluding stable technical patterns.

Step 11: command names and code

Software documentation may contain:

• git commit
• npm install
• --force
• /api/v2
• user_id

These should usually remain unchanged.

But surrounding prose must translate.

Same-as-source QA is particularly useful for detecting when a whole code explanation was copied instead of only the code.

Worked example 4: mixed code and prose

Source:

Run npm install before building the project.

Target:

Run npm install before building the project.

The code token correctly remains.

The sentence does not.

Do not exempt the entire segment just because it contains code.

Segment-level checks can be too coarse

A segment may contain both:

• translatable prose;
• non-translatable code.

The QA tool sees full source-target equality.

That is useful.

If you globally ignore “segments with code,” you may hide real misses.

Prefer token-level exceptions where possible.

Step 12: acronyms

Examples:

• API
• CPU
• PDF
• KPI
• GDPR

Some acronyms remain.

Some have target-language forms.

Some require first-use expansion.

Use the acronym policy.

Do not whitelist every uppercase token blindly.

Step 13: loanwords

Some source words are naturally used unchanged in target language.

Examples vary by language and domain.

A word may be:

• fully borrowed;
• partially localized;
• rejected by client style.

Same-as-source QA cannot know sociolinguistic acceptability.

That remains a language decision.

Step 14: short numeric or symbol strings

Source:

404

Target:

404

Correct.

Source:

50%

Target:

50%

Potentially correct.

Source:

OK

Target:

OK

May be correct or may require translation depending on interface and locale.

Again, classify by function.

Step 15: normalize whitespace carefully

Some same-as-source checkers compare after trimming outer spaces.

That is useful because:

Delete account

and

Delete account

should still count as essentially identical for untranslated detection.

But do not normalize so aggressively that meaningful differences disappear.

Examples:

• punctuation;
• Unicode normalization;
• full-width forms;
• bidirectional markers.

The check should answer one question clearly.

Same-as-source versus capitalization QA

Source:

LOGIN

Target:

Login

Not identical.

But perhaps still untranslated if target language should use another word.

Same-as-source checks catch exact equality, not semantic untranslatedness.

Other checks are still needed.

Same-as-source versus language detection

A target can differ slightly from source and still be mostly source language.

Example:

Source:

Delete your account now.

Target:

Delete your account maintenant.

Not identical.

Same-as-source QA may miss it.

Target-language detection or source-residue checks can catch it.

Layered QA matters.

Step 16: use target-language detection as a second net

Current localization platforms increasingly offer Target in the wrong language checks.

This complements exact same-as-source detection.

Same-as-source catches:

Delete account → Delete account

Wrong-language detection may catch:

Delete account → Delete le compte

Use both for multilingual release QA.

Step 17: do not ignore all identical warnings at once

Bulk ignoring feels attractive when the report contains many brands and codes.

It is dangerous.

One missed user-facing sentence can hide among 100 legitimate identifiers.

Better:

1. classify repeated non-translatable patterns;
2. formalize safe exceptions;
3. rerun;
4. inspect remaining natural-language findings.

Reduce noise structurally.

Step 18: exception design

A good exception should be:

• narrow;
• evidence-based;
• reusable;
• explainable.

Examples:

• exact brand name AcmeCloud;
• regex for version numbers;
• project termbase entry marked do-not-translate.

Bad exception:

ignore every target equal to source if shorter than 12 characters.

That can hide buttons such as:

• Delete
• Cancel
• Retry
• Confirm

Step 19: build an allowlist

For recurring projects, maintain a small allowlist of stable identical items.

Categories:

• brand names;
• product names;
• standards;
• file extensions;
• approved acronyms.

Then same-as-source QA can focus on unexpected equality.

This is analogous to a custom spellcheck dictionary.

The key difference is purpose:

spellcheck allowlist says the word is spelled correctly.

same-as-source allowlist says identical preservation is expected.

Keep allowlists scoped

A term may be do-not-translate for one client but translatable for another.

Use:

• client scope;
• product scope;
• locale scope.

Global exceptions can hide real errors elsewhere.

Step 20: multi-translator projects

Different translators may have different habits.

Translator A translates immediately.

Translator B copies source first.

Translator C leaves empty targets.

A final completeness workflow should catch all forms.

Project-level same-as-source QA standardizes the check regardless of individual drafting style.

Step 21: reviewer changes can reintroduce source text

A reviewer may paste source text accidentally while rewriting.

Therefore run same-as-source QA after review, not only after translation.

Final QA should represent final state.

Step 22: machine translation can return source unchanged

MT systems sometimes return input unchanged when:

• token is unknown;
• content looks like code;
• named entity dominates;
• language detection fails;
• model chooses to preserve phrase.

For a full sentence, unchanged MT output deserves review.

Do not assume an MT-populated target is translated merely because the system filled it.

Step 23: translation memory can preserve old untranslated targets

A contaminated TM may contain source-identical target pairs created by previous workflows.

Those pairs can recur as exact matches.

Same-as-source QA can expose them.

Then inspect the memory under TM governance.

One project correction may not be enough if the bad pair remains reusable.

Worked example 5: contaminated TM

Source:

Reset password

TM target:

Reset password

Target locale:

Spanish.

The segment arrives as 100% match.

Translator trusts it.

Same-as-source QA flags it.

Root cause:

legacy TM stored untranslated target.

Repair both:

• current segment;
• bad TM entry.

Step 24: high-risk content gets no automatic exemption

Even if a phrase is short, inspect identical targets in:

• medicine;
• safety;
• legal;
• finance;
• consent;
• account deletion;
• security.

A two-word untranslated warning can matter greatly.

Step 25: use final-file spot checks

CAT QA verifies bilingual segments.

It may not detect text that never entered the CAT tool:

• images;
• embedded objects;
• generated UI;
• chart labels.

After same-as-source QA passes, inspect representative final output.

Completeness exists at product level, not only segment level.

Failure mode 1: every identical pair treated as error

Result:

brands and codes get “translated.”

Repair:

• controlled exceptions.

Failure mode 2: every short string ignored

Result:

buttons and statuses stay untranslated.

Repair:

• use context and keys.

Failure mode 3: non-empty target assumed complete

Result:

source-copied drafts escape.

Repair:

• same-as-source QA.

Failure mode 4: code-containing segments globally exempted

Result:

surrounding prose remains source language.

Repair:

• token-level protection.

Failure mode 5: TM exact matches trusted blindly

Result:

legacy untranslated target propagates.

Repair:

• run QA on reused content.

Failure mode 6: reviewer introduces source text after QA

Result:

final release fails despite clean translator stage.

Repair:

• rerun after review.

Failure mode 7: allowlist becomes too broad

Result:

real misses suppressed.

Repair:

• client/product/locale scope.

Failure mode 8: same-language adaptation overloaded with warnings

Result:

check loses value.

Repair:

• locale-specific rules and targeted scope.

Failure mode 9: transliteration assumed unnecessary

Result:

names remain in wrong script or form.

Repair:

• name policy.

Failure mode 10: hidden content never checked

Result:

final product still shows source language.

Repair:

• in-context or final-output review.

A same-as-source triage matrix

Finding	Likely action
full sentence identical	translate or investigate immediately
known brand identical	allow
model number identical	usually allow
UI button identical	inspect context
URL identical	usually allow
proper name identical	check naming policy
mixed code + prose identical	translate prose
same-language locale pair	apply locale-specific review

Build severity by string type

High

• warnings;
• consent;
• security;
• user actions;
• legal obligations.

Medium

• headings;
• general prose;
• help text.

Low

• identifiers;
• standards;
• technical codes.

Severity helps large projects move quickly.

Search-intent transfer: what users are really asking

People who search:

• “identical source target translation”
• “untranslated segments CAT tool”
• “same as source localization QA”
• “original string equals target string”