How People Translate Quickly | Regex QA: Build Custom Pattern Checks for Variables, Symbols, IDs and Required Target Forms

People searching translation regex QA, regular expression quality check, CAT tool custom QA rule, regex localization check, custom quality checks translation, forbidden in translation regex, missing in translation regex, or count mismatch translation QA are trying to solve a familiar problem: the standard QA panel catches many common defects, but the project has one special rule that matters enormously and exists nowhere in the default checklist.

Current localization platforms increasingly expose custom quality checks with regex for exactly this reason. Smartling, for example, describes three useful custom-check patterns—count mismatch in translation, forbidden in translation, and missing in translation—built from source and target regular expressions. This lets a localization team describe a machine-checkable project rule such as “every source copyright symbol must survive,” “the target must never contain this legacy product marker,” or “if the source contains this placeholder family, the translation must contain the matching target form.”

This article has one dominant reader job: build safe custom regex QA rules that catch project-specific translation defects automatically without creating a flood of false positives. It is not a general regular-expression programming tutorial, not a find-and-replace guide, and not an auto-translation-rules article. The focus is validation: how to describe a pattern, test it, scope it, assign severity, and use it as a high-signal quality gate.

Quick answer

A reliable regex-QA workflow is:

1. define the exact defect the rule should catch in plain language;
2. decide whether the rule is missing, forbidden, or count mismatch;
3. write the smallest source pattern that identifies when the rule applies;
4. write the smallest target pattern that proves the target passed or failed;
5. test positive examples, negative examples, and edge cases before enabling the rule;
6. set case sensitivity, multiline behavior, Unicode handling, and HTML decoding intentionally;
7. scope the rule by locale, project, file type, or content class where possible;
8. start with warning severity until precision is known;
9. measure false positives and refine;
10. promote only reliable rules into blocking release gates.

The key principle is:

write a regex for one failure mode, not for “bad translation” in general.

What regex adds to translation QA

Standard QA can already check:

• numbers;
• tags;
• placeholders;
• spelling;
• terminology;
• target length;
• punctuation.

Regex becomes useful when the project has a rule such as:

Every support ticket ID starts with SR- followed by six digits.

or:

In German target text, the old legal abbreviation AGB-alt must never appear.

or:

If a source contains ©, the target must preserve at least one ©.

These rules are simple for a pattern engine.

They are tedious for a human reviewer to scan repeatedly.

Regex is a pattern language

A regular expression describes a class of strings.

Examples:

\d+

matches one or more digits.

SR-\d{6}

matches SR- followed by exactly six digits.

^ERROR:

matches ERROR: at the beginning of a string.

https?://

matches strings beginning with http:// or https://.

You do not need advanced regex to build high-value translation QA.

Most useful rules are small.

The first design step is not syntax

Before typing symbols, write the policy in ordinary language.

Bad start:

I need a regex for this file.

Good start:

If the source contains a copyright symbol, the target must contain the same number of copyright symbols.

Now the QA type becomes obvious:

count mismatch.

Or:

The target must never contain Acme Classic.

That is:

forbidden in translation.

Or:

If the source contains %USER%, the target must also contain %USER%.

That is:

missing in translation or count mismatch, depending on how exact the requirement is.

Policy first.

Pattern second.

Three core custom-QA models

1. Count mismatch

Compare how many times a pattern appears in source and target.

Useful for:

• symbols;
• placeholders;
• legal marks;
• repeated tokens;
• paired technical markers.

2. Forbidden in translation

If a target pattern appears, flag it.

Useful for:

• old brand names;
• prohibited punctuation;
• source-language residue;
• unsafe abbreviations;
• deprecated legal forms.

3. Missing in translation

If a source trigger appears, require a target pattern.

Useful for:

• mandatory target phrase;
• legal symbol;
• required unit;
• locale-specific terminology form.

These three models cover a surprising amount of practical QA.

Worked example 1: preserve copyright symbols

Policy:

The target must contain the same number of © symbols as the source.

Source regex:

©

Target regex:

©

Check type:

count mismatch.

Source:

© 2026 Acme. © Product Division.

Target:

© 2026 Acme. Product Division.

Source count: 2.

Target count: 1.

Flag.

The checker does not need to understand copyright law.

It counts the structural signal.

Worked example 2: ban a legacy term

Policy:

Target must never contain Acme Classic.

Source trigger:

.*?

Target pattern:

Acme Classic

Check type:

forbidden in translation.

Using a source pattern that matches anything means the target is checked regardless of source content.

This is useful for project-wide block rules.

Worked example 3: require a target marker only when source marker exists

Policy:

If the source contains [IMPORTANT], the target must include the approved target marker [WICHTIG].

Source regex:

\[IMPORTANT\]

Target regex:

\[WICHTIG\]

Check type:

missing in translation.

The rule activates only where the source trigger appears.

That keeps the warning list narrow.

Step 1: escape literal characters correctly

Regex uses special characters:

• .
• *
• +
• ?
• (
• )
• [
• ]
• {
• }
• ^
• $
• |
• \

If you want to match them literally, they may need escaping.

Example:

To match a literal period:

\.

To match [OK]:

\[OK\]

To match C++ safely:

C\+\+

Failure to escape can make the rule much broader than intended.

The dot is especially dangerous

Regex:

.

means roughly “any character.”

Literal period:

\.

A rule intended to find .com but written as .com may match many unintended sequences.

Small syntax errors can create massive false positives.

Test before enabling.

Step 2: anchor when position matters

^ means beginning.

$ means end.

Policy:

Every target line must begin with • .

Target regex:

^•\s

Without the start anchor, the bullet could appear anywhere and still pass.

Use anchors when position is part of the rule.

Multiline changes anchor behavior

In multiline mode, ^ and $ may also match the beginning and end of each line, not just the whole segment.

This is useful for:

• subtitles;
• multiline help text;
• lists.

It can also change results dramatically.

Enable multiline only when the rule needs line-level behavior.

Step 3: choose case sensitivity intentionally

Pattern:

API

Case-sensitive:

matches API, not api.

Case-insensitive:

matches both.

For a brand or acronym, case may matter.

For a forbidden lexical term, it may not.

Do not leave case mode to default by accident.

Worked example 4: brand capitalization

Policy:

Target must never contain lowercase acmecloud.

A case-sensitive forbidden rule can flag only the lowercase form.

If the rule is case-insensitive, it may also flag the correct AcmeCloud.

The pattern mode must reflect the policy.

Step 4: use word boundaries for lexical terms

Suppose you want to forbid the target word:

net

Pattern:

net

This may match:

• internet;
• network;
• planet.

If the regex engine supports word boundaries:

net

is safer for a standalone word.

But word-boundary behavior varies across languages and Unicode scripts.

Test it with real target-language examples.

Do not assume English word-boundary logic works everywhere

Languages may:

• omit spaces;
• form compounds;
• attach suffixes;
• use scripts with different segmentation.

A boundary rule perfect for English may fail for Japanese, Chinese, Thai, German compounds, or inflected languages.

Regex QA must respect the language.

Step 5: use character classes carefully

[A-Z]

matches ASCII uppercase letters.

It does not represent every uppercase letter in every language.

Unicode-aware engines may support properties such as:

\p{L}

for letters or script-specific properties.

But support varies.

Never assume regex flavor.

Regex flavor matters

Different systems may use:

• JavaScript regex;
• .NET regex;
• Java regex;
• PCRE-like syntax;
• ICU rules.

Features can differ:

• lookbehind;
• Unicode properties;
• named groups;
• flags.

A pattern that works in an online tester may fail in the CAT platform.

Test inside the real system.

Step 6: test at least four classes of examples

Before enabling a rule, test:

True positive

A real error that must be flagged.

True negative

A correct target that must pass.

Near miss

Something similar that should not be flagged.

Edge case

Punctuation, line break, capitalization, HTML entity, or Unicode variation.

A regex is not ready after one successful example.

Test tables are faster than intuition

Example rule: forbid old brand Cloud One.

Target	Expected
Cloud One	fail
Cloud One Pro	fail
CloudOne	pass or fail depending on policy
cloud one	depends on case rule
“Cloud One”	fail
Cloud One-time offer	probably fail if literal brand phrase exists

This table exposes the real policy.

Step 7: distinguish count mismatch from missing

Suppose source contains two placeholders:

{0} and {1}.

Target contains only {0}.

A “missing at least one placeholder” rule may pass because one exists.

A count or exact-token check is stronger.

Choose the QA type based on how much structure must be preserved.

Step 8: match paired source-target transformations carefully

Sometimes source and target patterns differ.

Source:

kg

Target locale policy:

kg

Same pattern.

But source:

AM

Target:

locale-specific equivalent.

You can trigger on source form and require target form.

This is powerful.

It can also overconstrain translation if context varies.

Use only for stable rules.

Step 9: regex can validate IDs

Policy:

Ticket IDs must preserve SR- plus six digits.

Pattern:

SR-\d{6}

But this alone does not prove the same digits survived.

Source:

SR-123456

Target:

SR-654321

Both match.

For exact identity, use placeholder/insertable QA or a more sophisticated source-target comparison if the platform supports it.

Regex validates shape.

It may not validate identity.

Pattern correctness versus value correctness

This distinction is essential.

Regex can prove:

This looks like a valid ticket ID.

It may not prove:

This is the same ticket ID as the source.

Use the right check.

Step 10: use regex for forbidden characters

Examples:

• ampersand not allowed in a target channel;
• ASCII punctuation forbidden after CJK text;
• tab characters forbidden;
• straight quotes forbidden in publication copy.

Regex is useful when standard QA does not cover the exact local rule.

But first check whether the platform already has a native QA option.

Native rules may be easier to maintain.

Do not recreate standard QA unnecessarily

If the tool already checks:

• numbers;
• placeholders;
• repeated words;
• legal symbols;

use the standard check.

Custom regex should fill real gaps.

Every custom rule adds maintenance.

Step 11: HTML entities complicate matching

The visible target may contain:

&

while the underlying string stores:

&

Some platforms can decode HTML entities before regex evaluation.

If the rule is about what users see, decoding may be appropriate.

If the rule is about raw markup, it may not.

Know which layer you are validating.

Worked example 5: ampersand rule

Policy:

Target display text must not contain &.

If HTML entity decoding is off, target containing & might escape the rule.

If decoding is on, it becomes visible as & for evaluation.

The platform setting changes the result.

Step 12: use regex for mandatory legal phrases only with strong governance

Example:

If source contains a statutory warning marker, target must contain the approved legal phrase.

This can be valuable.

But legal language may inflect or vary by grammatical context.

A rigid string regex can force awkward or wrong phrasing.

Where language requires variation:

• use termbase;
• use lemma-aware terminology;
• use human review.

Regex is strongest for structural invariants.

Step 13: use regex for variables and tokens

Examples:

• %USER%
• {{name}}
• ${amount}
• <0>
• %1$s

These are high-value validation targets.

But many CAT tools already have placeholder QA.

Use custom regex only when:

• syntax is proprietary;
• standard parser misses it;
• project token has special rule.

Step 14: use regex for file-specific syntax

A documentation project may contain custom directives:

::warning::

{product_id}

[[LinkTarget]]

If the CAT tool treats them as normal text, regex can guard them.

This is a strong use case because the project syntax is deterministic and repetitive.

Step 15: scope custom checks by locale

A rule valid in French may be wrong in English.

A punctuation regex valid in Chinese may be irrelevant in German.

If the platform supports language-specific configuration, use it.

Do not create one global “perfect regex” for all target languages.

Step 16: scope by content type

Marketing copy and software strings may use different rules.

Example:

Ampersand may be banned in prose but required in a UI brand label.

Use:

• project scope;
• file scope;
• channel scope.

Context reduces false positives.

Step 17: assign severity conservatively

Many platforms let you set:

• low;
• medium;
• high;
• blocking.

Start new custom rules as warnings.

Measure precision.

Only make them blocking when:

• rule is unambiguous;
• false-positive rate is low;
• consequence justifies it;
• override process exists.

A bad blocking regex can stop an entire translation workflow.

Step 18: false positives are configuration debt

If translators ignore the same wrong warning 500 times, the project is paying for a bad rule.

Fix it.

Possible repairs:

• narrower source trigger;
• better target boundary;
• locale scope;
• case mode;
• exclude tags;
• allow specific exceptions.

A custom QA rule should become more precise over time.

Step 19: false negatives matter too

A rule that never warns may simply be broken.

Test deliberately.

Example:

If the rule should forbid &, enter a target containing &.

Save or confirm.

Confirm the warning appears.

Every important rule should have a known failing test.

Step 20: create a QA fixture file

For recurring localization programs, maintain a small test project containing:

• one passing example;
• one failing example;
• edge cases for every critical custom rule.

When the TMS changes or rules are edited, rerun the fixture.

This is the localization equivalent of regression testing.

Regression testing for QA rules

A QA configuration can break after:

• platform update;
• regex edit;
• locale change;
• file-format change.

The fixture proves the rule still behaves.

Do not assume yesterday’s QA configuration remains correct forever.

Step 21: use descriptive rule names

Bad:

Regex 7

Good:

BLOCK old product name Acme Classic

Good:

REQUIRE © when source contains ©

Good:

COUNT %{n} placeholders

The name should tell the translator what the warning means.

A warning that requires reverse-engineering the regex wastes time.

Warning messages should explain action

Bad:

Regex validation failed.

Better:

Target contains the deprecated product name “Acme Classic”. Replace with current approved product name.

The regex is implementation.

The warning is user interface.

Write it for translators, not programmers.

Step 22: document the rule owner

Every custom QA rule should have an owner.

Possible owner:

• localization engineer;
• language lead;
• product localization PM;
• terminology manager.

Why?

Because rules become stale.

Someone must decide when:

• brand changes;
• syntax changes;
• target policy changes;
• false positives appear.

Step 23: version the rule set

If custom QA is critical, record versions:

• QA profile v1;
• v2 after product rename;
• v3 after new placeholder syntax.

This helps explain why older projects produced different warning behavior.

Step 24: regex and escaping in JSON or configuration files

Sometimes the regex itself is stored inside:

• JSON;
• YAML;
• XML.

Then backslashes may need extra escaping.

Example conceptual regex:

\d+

Inside JSON string may appear as:

\d+

This is not “double regex.”

It is string encoding around regex.

Test in the actual configuration environment.

Step 25: avoid catastrophic or expensive patterns

Poorly designed regex can be slow on long strings.

Patterns with ambiguous nested repetition can cause excessive backtracking in some engines.

For translation QA, keep patterns simple.

Prefer:

• explicit character classes;
• bounded repetition;
• clear anchors.

You rarely need a heroic regex.

Simple patterns are easier to audit

A 90-character regex may be clever.

A 20-character regex may be maintainable.

Custom QA is infrastructure.

Other people need to understand it later.

Prefer clarity.

Failure mode 1: source trigger too broad

Every segment is evaluated.

Result:

warning flood.

Repair:

• narrow source condition unless global check is intended.

Failure mode 2: target regex too broad

Harmless words match.

Repair:

• boundaries and context.

Failure mode 3: online tester differs from CAT engine

Pattern works in browser, fails in TMS.

Repair:

• test in platform.

Failure mode 4: case setting wrong

Correct brand form gets flagged.

Repair:

• explicit case policy.

Failure mode 5: multiline mode wrong

Anchors behave unexpectedly.

Repair:

• test line-level examples.

Failure mode 6: HTML entity mismatch

Visible symbol escapes detection.

Repair:

• choose decode policy.

Failure mode 7: blocking severity too early

Translators cannot submit correct exceptions.

Repair:

• start as warning.

Failure mode 8: one regex tries to solve five rules

Impossible maintenance.

Repair:

• one failure mode per check.

Failure mode 9: regex validates format but not value identity

Wrong ID passes.

Repair:

• use source-target comparison or placeholder QA.

Failure mode 10: rule never tested after setup

It silently stops working.

Repair:

• QA fixture and regression test.

A pattern-design checklist

Before activating a custom check:

• plain-language policy written?
• source trigger needed?
• target pass/fail condition defined?
• check type chosen?
• case mode set?
• multiline set?
• Unicode behavior tested?
• HTML decoding understood?
• positive test passes?
• negative test fails?
• edge cases tested?
• severity appropriate?

If those answers are clear, the rule is ready for pilot use.