How People Translate Quickly | Target-Language Script Check: Catch Source-Language Residue, Wrong Alphabets and Forbidden Characters Before Delivery

People searching target in the wrong language, translation wrong language check, forbidden characters translation QA, source-language residue, wrong alphabet localization, target script check, or find untranslated words in target language are trying to catch a failure that can survive ordinary proofreading: the target contains characters or words from a language or script that should not be there.

Current localization QA systems increasingly expose checks such as Target in the wrong language, Source in the wrong language, and forbidden characters. XTM-oriented QA guidance, for example, lists forbidden characters and identical source-and-target among language checks, while Smartling includes target-in-the-wrong-language as a quality check that can run while linguists work. The reason is practical: a target can be grammatically polished overall and still contain one source-language word, one Latin-script fragment in a target that should be fully localized, one obsolete character, or one punctuation form forbidden by locale policy.

This article has one dominant reader job: use target-language, script, and forbidden-character checks to find source-language residue and wrong-script text quickly without flagging legitimate brands, acronyms, codes, URLs, or approved mixed-script content. It is not a general Unicode article, not a spelling guide, and not a same-as-source check. The focus is the target character and language layer: does this target look like text that belongs in the intended locale?

Quick answer

A practical wrong-language/script workflow is:

1. define what scripts and language forms are normally expected in the target;
2. run target-language and forbidden-character QA where available;
3. identify unexpected source-language words or script runs;
4. separate real residue from legitimate brands, codes, acronyms, names, and technical tokens;
5. use allowlists and scoped rules instead of globally disabling the check;
6. configure locale-specific forbidden characters only where the rule is stable;
7. review mixed-script strings with context;
8. combine script checks with same-as-source QA, terminology QA, and spellcheck;
9. rerun after reviewer edits, imports, and bulk replacements;
10. finish with a final residual-source-language sweep before release.

The central rule is:

unexpected script is a clue; context decides whether it is an error.

Why wrong-language residue is easy to miss

Consider this target:

Cliquez sur Save pour continuer.

A French reviewer reading quickly may understand it instantly.

The English word Save is familiar.

That familiarity can make it less visible.

But if the product requires full localization, the target is incomplete.

Human fluency sometimes hides source-language residue because the borrowed word remains comprehensible.

Automated language and script checks provide a second set of eyes.

Script and language are not the same thing

English, French, German, Spanish, and many other languages use Latin script.

A Latin-script detector cannot distinguish them reliably.

Japanese may contain:

• Kanji;
• Hiragana;
• Katakana;
• Latin letters;
• Arabic digits.

Serbian may use Cyrillic or Latin depending on locale and policy.

Chinese target text may legitimately contain Latin product names.

Therefore there are two related but distinct checks:

Script check

Are the characters from expected writing systems?

Language check

Does the text appear linguistically to belong to the intended language?

A robust workflow may use both.

Step 1: define the expected script profile

Before flagging “wrong script,” define normal target behavior.

Example: Japanese UI.

Expected:

• Japanese scripts;
• ASCII digits;
• approved Latin product names;
• standard technical abbreviations.

Unexpected:

• long English natural-language fragments;
• unapproved source UI labels;
• stray Cyrillic characters.

The profile is not “Japanese only.”

It is a controlled mixed-script environment.

Step 2: identify high-confidence residue

High-confidence examples:

English source → Japanese target:

Please restart the device.

appears unchanged inside otherwise Japanese text.

German source → Greek target:

a full German clause remains.

Arabic target:

an English legal sentence remains in the middle.

These are strong candidates.

The longer and more grammatical the unexpected source-language run, the stronger the evidence.

Step 3: do not flag every Latin token

Many target languages legitimately contain Latin-script items:

• USB;
• Wi-Fi;
• HTML;
• PDF;
• iPhone;
• OpenAI;
• URL;
• email addresses;
• model numbers.

A blanket “no Latin letters” rule would create constant false positives.

Better:

• allow known technical tokens;
• allow brand names;
• flag long Latin runs;
• flag specific source-language words.

Precision matters.

Worked example 1: Japanese target

Source:

Open the Settings menu.

Target:

Settings メニューを開きます。

Is Settings intentional?

Check:

• product UI screenshot;
• approved glossary;
• source key;
• existing Japanese interface.

If the actual UI button remains English by product design, the target may be correct.

If the Japanese UI uses a localized label, this is residue.

The script check found the decision point.

Step 4: use word-level source-language dictionaries carefully

One way to detect residue is to search for common source-language words.

English examples:

• the;
• and;
• click;
• save;
• cancel;
• account.

This can work in targets that rarely use English.

But common strings can collide with names or acronyms.

A language detector or contextual rule is usually stronger than one forbidden word list.

Function words are strong residue signals

Content words are often borrowed.

Function words are less likely to be intentionally borrowed.

A target containing source-language sequences such as:

• the;
• of;
• to;
• and;
• is;

inside a non-English target can be more suspicious than one technical noun.

This is not universal, but it is useful triage.

Step 5: use forbidden characters for stable locale rules

Some projects prohibit specific characters.

Examples:

• ASCII ? after ideographic text;
• straight quotes in publication copy;
• tab characters;
• deprecated code-page symbols;
• full-width Latin where half-width is required;
• unsupported control characters.

These are good automated rules because they are deterministic.

Forbidden-character rules need scope

A character may be forbidden in:

• one locale;
• one channel;
• one file type.

Do not apply it globally unless the policy is truly global.

Example:

&

may be prohibited in formal prose but required in a brand name.

Scope the check.

Step 6: distinguish punctuation script from language residue

Source English punctuation can remain in a CJK target even when all words are translated.

Example Japanese target ends with ASCII ? instead of the project’s approved full-width punctuation.

This is not untranslated language.

It is locale typography.

A forbidden-character rule can catch it.

Keep the diagnostic category clear.

Step 7: detect accidental Cyrillic-Latin confusables

Some characters look visually similar:

• Latin A and Cyrillic А;
• Latin C and Cyrillic С;
• Latin P and Cyrillic Р;
• Latin x and Cyrillic х.

A copy-paste can introduce wrong-script characters that look normal.

This matters in:

• identifiers;
• product names;
• URLs;
• technical content.

Script-aware QA can expose them.

Confusable characters can become security issues

In URLs and identifiers, visually similar Unicode characters can create spoofing risk.

Translation teams should not casually normalize or replace identifiers.

If a protected string contains mixed scripts unexpectedly, escalate.

Do not “fix” a URL by visual intuition.

Step 8: watch source language in reviewer comments imported as target

Bilingual review workflows can accidentally import:

• comment text;
• reviewer explanation;
• source snippets;

into target fields if mapping is wrong.

A target-language check may reveal the contamination.

This is a structural workflow problem, not a translator-language problem.

Investigate import path.

Step 9: machine translation can produce mixed-language output

MT or LLM translation may:

• leave named entities;
• preserve difficult technical terms;
• leave source clauses;
• mix languages;
• code-switch.

A fluent overall sentence can hide one source fragment.

Run target-language checks after MT post-editing.

Do not rely on model self-confidence.

Worked example 2: partial MT residue

Source:

The controller enters recovery mode after three failed attempts.

Target:

Der Controller wechselt nach drei failed attempts in den Wiederherstellungsmodus.

The sentence is partly German, partly English.

Same-as-source QA does not catch it because the whole target differs.

Wrong-language detection can.

Step 10: borrowed terminology needs governance

Many technical domains intentionally use source-language terms.

Examples:

• cloud;
• login;
• API;
• server.

Whether they are acceptable depends on target locale and client style.

A script detector cannot resolve that.

Use:

• termbase;
• style guide;
• domain convention.

The QA warning should trigger verification, not automatic replacement.

Step 11: proper names and transliteration

A proper name may:

• stay in source script;
• be transliterated;
• use established translated form.

Examples depend on locale.

A target-script policy should specify:

• person names;
• place names;
• institutions;
• brands.

Otherwise wrong-language QA can create endless debates.

Step 12: numbers and mathematical symbols

Arabic digits are widely used across scripts.

They should not trigger wrong-language warnings by default.

Mathematical notation may include:

• Latin variables;
• Greek letters;
• operators.

These are technical symbols, not source residue.

Context matters.

Step 13: chemical formulas

H2O

NaCl

CO2

should remain.

A broad Latin-letter ban would fail.

Technical notation belongs in an allowlist or protected pattern.

Step 14: URLs and domain names

URLs often remain ASCII or use internationalized domain rules.

Do not translate or alter them based on script appearance.

A long Latin-script URL inside Arabic or Japanese target is expected.

Use URL recognition to exclude it from residue checks.

Step 15: email addresses

Same principle.

support@example.com

is not source-language prose.

Exclude structured identifiers.

Step 16: file paths and commands

Examples:

C:\Program Files\App

/usr/local/bin

git push

These can remain source-like.

Protect them.

But translate surrounding instructions.

Worked example 3: command plus residue

Target:

git push を実行して then restart the service.

git push is protected command.

then restart the service is residue.

Token-aware review is necessary.

Step 17: detect wrong source language before translation too

Some platforms can flag Source in the wrong language.

This is useful when a project expected English source but one file is Spanish.

Why does it matter?

• wrong MT engine routing;
• wrong translator assignment;
• wrong terminology;
• bad word counts.

Language QA begins before target production.

Step 18: mixed-language source may be legitimate

A source document can intentionally contain:

• quotes;
• foreign product names;
• bilingual examples;
• code.

Source-language detection should also use context.

The same principle applies:

unexpected language is a signal, not automatic error.

Step 19: target-language detection is probabilistic

Language identification tools infer language from text.

Short strings are difficult.

Examples:

• OK
• No
• Menu
• Pro

Some are valid words in several languages.

Do not expect perfect classification on one-word segments.

Use script, key, context, and terminology.

Short-string language detection should have lower authority

A 50-word English paragraph in a French target is strong evidence.

A two-letter token is not.

Severity should reflect evidence strength.

Step 20: set minimum-length thresholds where possible

If the platform or custom tooling supports it, run language detection only above a useful length.

This can reduce noise from:

• acronyms;
• codes;
• tiny UI labels.

Then use dedicated UI review for short strings.

Step 21: use regex to detect long source-script runs

When native language detection is unavailable, a custom regex can approximate some checks.

Example concept:

• target should rarely contain long sequences of Latin letters;
• flag runs longer than 20 characters;
• exclude URLs and approved brands.

This is not true language detection.

It is a practical residue detector.

Step 22: build script allowlists

For a Japanese target:

Allowed Latin tokens may include:

• USB;
• Wi-Fi;
• CPU;
• approved brand names.

For an Arabic target:

Allow:

• product codes;
• URLs;
• email addresses;
• standard abbreviations.

A scoped allowlist improves precision.

Step 23: build forbidden lists for source UI terms

If the source product contains English labels that should always be localized, list them:

• Settings;
• Save;
• Delete;
• Cancel.

A target containing these exact source UI terms can trigger high-value warnings.

This is more precise than banning all English.

Step 24: check capitalization and script together

Wrong script can hide in case.

Example:

a Cyrillic character inside an uppercase acronym.

Visually the acronym looks normal.

A script check can catch it even when spellcheck cannot.

This is especially relevant to:

• identifiers;
• security-sensitive names;
• regulatory labels.

Step 25: Unicode invisible characters

Some forbidden-character workflows also catch:

• zero-width spaces;
• nonbreaking spaces;
• directional controls;
• stray control characters.

These are not “wrong language” in the ordinary sense.

But they belong in the character-integrity layer.

If the project needs them intentionally, document it.

If not, remove them carefully.

Bidirectional marks require special caution

Arabic and Hebrew content may legitimately need bidirectional controls.

Do not globally ban invisible characters.

A character that looks suspicious in Latin text may be necessary in mixed RTL/LTR layout.

Locale expertise matters.

Step 26: wrong alphabet in transliteration

A transliterated name can mix scripts accidentally.

Example:

mostly Latin target name with one Cyrillic letter.

This may not be visible to human eye.

Script validation can protect:

• passport-style names;
• database keys;
• product identifiers.

Step 27: source residue in subtitles

Subtitles often contain:

• speaker names;
• song titles;
• signs;
• foreign-language dialogue.

A wrong-language warning may be intentional if the scene includes multilingual speech.

Use audiovisual context.

Do not force all subtitle text into one language when the story intentionally code-switches.

Step 28: source residue in educational content

Language-learning material may intentionally preserve source-language examples.

Example:

A French lesson for English-speaking students includes French phrases and English explanations.

A blanket wrong-language check is inappropriate.

Scope by content purpose.

Step 29: source residue in legal quotations

A legal translation may preserve quoted original language with translated explanation.

Again, context.

The target-language checker should not overrule document function.

Step 30: multi-locale products

One brand may intentionally mix:

• English feature names;
• local target prose;
• international legal symbols.

Write the locale profile once.

Do not leave every translator to invent the mixture.

Failure mode 1: ban all Latin characters

Result:

URLs, brands, and acronyms break.

Repair:

• allowlists and pattern exclusions.

Failure mode 2: trust language detection on one-word strings

Result:

false positives.

Repair:

• context and threshold.

Failure mode 3: ignore all English in technical target

Result:

real residue survives.

Repair:

• distinguish approved terms from full phrases.

Failure mode 4: treat wrong punctuation as translation error

Result:

diagnosis unclear.

Repair:

• separate character/typography rules.

Failure mode 5: automatic transliteration of names

Result:

identity changes.

Repair:

• approved name policy.

Failure mode 6: remove invisible RTL marks blindly

Result:

reading order breaks.

Repair:

• bidi-aware review.

Failure mode 7: reviewer introduces source-language word

Result:

final QA differs from translator-stage QA.

Repair:

• rerun after review.

Failure mode 8: imported comments contaminate target

Result:

wrong-language fragments appear.

Repair:

• inspect workflow mapping.

Failure mode 9: mixed-language educational or subtitle content overcorrected

Result:

intended multilingual meaning erased.

Repair:

• scope by content purpose.

Failure mode 10: confusable characters overlooked

Result:

identifier or name contains wrong script.

Repair:

• script-aware validation.

A practical warning triage

When target-language QA flags a segment:

Long unexpected natural-language phrase

High suspicion.

One approved brand

Likely legitimate.

Short ambiguous UI word

Check key/screenshot.

URL or email

Usually legitimate.

Mixed-script identifier

High technical risk.

Foreign-language quotation

Check document purpose.

This classification makes the warning list manageable.

Wrong-language QA and same-as-source QA

These two checks form a useful pair.

Same-as-source

Finds target equal to source.

Wrong-language

Finds target that may still contain source language even after some editing.

Together they catch:

• untouched source copy;
• partial source residue.

Wrong-language QA and spellcheck

Spellcheck may flag source-language residue as unknown target words.

That can help.

But spellcheck dictionaries often contain:

• brands;
• loanwords;
• technical terms.

Language detection adds another signal.

Wrong-language QA and glossary compliance

If an English technical term is allowed, the glossary can formalize it.

Then wrong-language warnings are easier to dismiss or exclude.

Terminology governance reduces language-detection noise.

Wrong-language QA and regex QA

Regex can implement:

• forbidden characters;
• script ranges;
• source UI terms.

Language detection handles broader linguistic patterns.

Use regex for deterministic structure.

Use language detection for probabilistic language evidence.

A target-script project card

For a recurring locale, document:

Primary scripts: expected writing systems.

Allowed Latin: brands, acronyms, codes.

Forbidden source terms: known UI labels.

Punctuation: locale policy.

Names: transliteration rule.

Identifiers: preserve exactly.

This one-page card can eliminate repeated uncertainty.

A five-minute setup test

Before launch:

1. enter one correct target sentence;
2. enter one full source-language sentence in target;
3. enter one approved brand;
4. enter one URL;
5. enter one mixed-script typo.

Verify the QA behavior.

If the rule cannot distinguish these categories, adjust before scale.

A final release sweep

Before delivery:

1. run target-language QA;
2. filter long unexpected source-language runs;
3. inspect source UI terms;
4. inspect mixed-script identifiers;
5. confirm approved brands and acronyms;
6. review forbidden-character warnings;
7. rerun after fixes.

Search-intent transfer

People searching:

• “target in wrong language”
• “translation wrong alphabet”
• “forbidden characters localization”
• “source language left in target”
• “find untranslated words”

want a practical residue-detection workflow.

The article should therefore own:

language signal + script signal + exception model + final release sweep.

A deeper mechanism: script entropy

You do not need a mathematical model to use this idea.

A target language normally has a characteristic script mixture.

Example Japanese UI may contain:

• mostly Japanese characters;
• some digits;
• occasional Latin abbreviations.

A segment with 90% English letters is statistically unusual.

The more a segment deviates from the normal script profile, the more it deserves review.

This is useful triage even when exact language detection is uncertain.

Project-scale anomaly detection

If most German target files contain 1–2% English tokens but one file contains 35%, investigate.

Possible causes:

• untranslated file;
• wrong import;
• MT failure;
• wrong target locale.

Aggregate script statistics can reveal workflow defects quickly.

Do not use anomaly rate as proof

A technical glossary may legitimately contain many English abbreviations.

A source file full of command examples may too.

The metric points to files worth inspection.

It does not replace context.

A mature residue-control stack

Layer 1

Same-as-source check.

Layer 2

Target-language detection.

Layer 3

Forbidden-character/script rules.

Layer 4

Terminology and do-not-translate allowlists.

Layer 5

Human in-context review.

Each layer catches a different failure class.

Why this improves speed

Without automation, reviewers scan every target looking for stray source words.

With a wrong-language/script report, attention goes to anomalous strings.

That is a classic high-value division:

machine finds improbable patterns;

human interprets them.

Final operating model