How People Translate Quickly | Number Verification: Compare Numbers, Dates, Percentages and Units Before They Become Silent Errors

People searching translation number verification, CAT tool number check, missing numbers translation QA, extra numbers target translation, date and unit verification in translation, or how to compare source and target numbers automatically are usually trying to prevent a class of error that looks small on screen and can become very large in consequence.

Current CAT and TMS quality-assurance systems still include dedicated numeric checks because numbers are easy to copy incorrectly, easy to overlook in fluent target text, and often more consequential than a stylistic sentence difference. A translator can produce a beautifully natural sentence and still change 30 to 300, 0.5 mg to 5 mg, 15% to 51%, 2026-09-19 to 2026-09-29, or 40 °C to 40 °F. The target may read smoothly while the underlying fact is wrong.

This article has one dominant reader job: use source-target number verification to catch missing, extra, changed, reformatted, or contextually wrong numeric information before delivery. It is not a general QA-profile guide, not a guide to translating measurements, and not an auto-translation-rules article. The focus is verification: compare what the source says numerically with what the target actually contains, then distinguish legitimate localization from real data loss.

Quick answer

A fast number-verification workflow is:

1. enable or run the CAT tool’s source-target number checks;
2. review missing numbers in the target;
3. review extra numbers in the target;
4. inspect changed values even when the sentence otherwise looks identical;
5. distinguish value changes from permitted locale formatting;
6. check units, percentages, decimal separators, thousand separators, currencies, dates, times, ranges, and signs;
7. verify conversions only when the project explicitly requires conversion;
8. treat high-risk numeric content as a separate review class;
9. rerun number QA after global edits, reviewer changes, or MT post-editing;
10. perform a final numeric sweep before export.

The central rule is:

numbers are meaning, not decoration.

Why numbers escape ordinary reading

Human readers do not process every character equally.

When reading:

The device operates at a maximum pressure of 45 bar under normal conditions.

the eye may focus on the sentence structure and technical phrase “maximum pressure.”

A reviewer familiar with the content may mentally expect 45 and fail to notice that the target says 54.

This is a form of expectation-driven reading.

Automated number comparison helps because it does not “understand” the sentence in the same way.

It simply asks:

Does the numeric content in source and target still correspond?

That mechanical comparison is valuable.

Numbers can be linguistically small and operationally huge

Examples:

• medication dosage;
• financial amount;
• deadline;
• interest rate;
• temperature limit;
• pressure threshold;
• product model;
• legal clause number;
• invoice number;
• phone number;
• measurement tolerance;
• software version.

A one-character numeric error can change action, safety, identity, or money.

Therefore number QA deserves its own workflow.

The main numeric error classes

Missing number

Source contains a number.

Target does not.

Extra number

Target contains a number that source does not.

Changed number

Source and target contain different values.

Formatting difference

The same value is written differently because of locale.

Unit difference

Value may be same but unit changed.

Conversion difference

Value and unit both changed intentionally.

Range error

Endpoints, dash, inequality, or order changed.

Sign error

Plus/minus, negative sign, percentage sign, currency symbol, or comparator changed.

Each class requires different interpretation.

Step 1: review missing numbers

Source:

Submit the report within 30 days.

Target:

Submit the report within the required period.

The translation may sound natural.

But the explicit deadline disappeared.

Number QA should flag it.

Ask:

• was omission intentional?
• did grammar absorb the number?
• did MT omit it?
• did translator simplify too aggressively?

In most procedural contexts, the number must remain.

Worked example 1: legal deadline

Source:

Appeals must be filed within 14 calendar days.

Target accidentally says:

Appeals must be filed within the deadline.

This loses legal specificity.

A general fluency review might miss it because the sentence remains grammatical.

Number verification catches the structural mismatch immediately.

Step 2: review extra numbers

Source:

The warranty covers manufacturing defects.

Target:

The warranty covers manufacturing defects for 24 months.

Where did 24 months come from?

Possibilities:

• translator imported knowledge from another version;
• MT hallucinated;
• old TM contributed extra content;
• reviewer inserted clarification;
• source omission exists.

An extra target number is not automatically wrong, but it demands evidence.

Extra numbers are especially suspicious in AI-assisted translation

Generative systems may occasionally introduce plausible values from context.

A fluent target can contain a number not present in source.

This is precisely the kind of issue deterministic QA can catch.

Use generative assistance for language.

Use deterministic comparison for numeric integrity.

Step 3: compare changed values token by token

Source:

1.5 mm

Target:

15 mm

The decimal point disappeared.

Source:

0.25%

Target:

25%

Two characters changed.

Meaning changed by a factor of 100.

Number QA should be configured to treat punctuation and decimal separators intelligently.

Decimal separators and locale

The same numeric value may appear as:

• 1.5
• 1,5

depending on locale.

A naive exact-string comparison might flag a legitimate localization.

The QA engine should ideally understand locale conventions.

If it does not, reviewers need a rule.

The question is:

Did the value change, or only the representation?

Thousand separators

Examples:

• 1,000.50
• 1 000,50
• 1.000,50
• 1000,50

These can represent the same quantity in different locales.

Verify the value, not only punctuation.

But also check project style.

Some clients may require nonbreaking spaces or specific grouping.

Step 4: check percentages as value plus symbol

Source:

15%

Target:

15

The number remains.

The percentage meaning disappeared.

Source:

15%

Target:

0.15%

A decimal interpretation error occurred.

Therefore numeric QA should consider:

• number;
• percent sign;
• surrounding unit.

The token “15” alone is not sufficient evidence.

Percentage-point differences

Source:

increased by 5 percentage points

Target:

increased by 5%

These are not necessarily equivalent.

Number verification may see the same number 5 and pass.

Human subject review must catch the semantic unit difference.

This illustrates a limit:

automated number checks compare numeric tokens.

They do not fully understand statistical concepts.

Step 5: verify units

Source:

50 kg

Target:

50 lb

Same number.

Different unit.

This may be:

• error;
• incomplete conversion;
• deliberate localization with wrong value.

If converting 50 kg to pounds, the number should change too.

Unit QA and number QA should work together.

Worked example 2: incomplete conversion

Source:

10 km

Target:

10 miles

The unit changed.

The quantity did not.

If conversion was intended, this is wrong.

If conversion was not intended, changing unit was wrong anyway.

Always treat conversion as a pair:

value + unit.

Step 6: do not convert unless policy says to convert

Translators sometimes “help” by converting:

• miles to kilometres;
• Fahrenheit to Celsius;
• dollars to local currency;
• inches to centimetres.

This can create factual drift.

Before converting, know:

• client policy;
• audience;
• legal requirements;
• rounding rule;
• whether original value should remain in parentheses.

Never infer conversion policy from intuition alone.

Conversion changes the verification problem

If conversion is permitted, source and target numbers will legitimately differ.

A basic number-mismatch checker may flag every converted value.

You then need:

• conversion QA;
• formula or calculator;
• tolerance rules;
• documented exception.

Intentional difference should be provable.

Step 7: verify temperatures carefully

Temperature conversion is not linear by simple multiplier alone.

Celsius/Fahrenheit conversion includes offset.

Source:

32 °F

Target:

0 °C

Correct conversion.

Source:

212 °F

Target:

100 °C

Correct.

A number checker may flag changed values.

Human or specialized rule must validate conversion.

Step 8: verify currencies as value, code, symbol, and meaning

Currency expressions can include:

• $;
• USD;
• SGD;
• €;
• EUR;
• ¥;
• JPY.

The symbol alone may be ambiguous.

Source:

$1,000

Target locale may require:

US$1,000

That can improve clarity.

But translating currency by replacing the symbol with target-market currency without conversion is wrong.

Currency localization requires explicit policy.

Exchange rates make automatic conversion risky

Currency values change over time.

If a project requires conversion:

• define reference rate;
• define date;
• define rounding;
• preserve source value where required.

Translation should not silently become financial calculation.

Step 9: verify dates

Dates are dangerous because formatting conventions differ.

03/04/2026

may mean:

• 3 April 2026;
• March 4, 2026.

A translator who changes format must first know the intended source date.

Prefer unambiguous formats where style permits.

Examples:

• 3 April 2026;
• 2026-04-03.

Number QA alone cannot disambiguate source convention.

Project context must.

Date order errors

Source:

2026-09-19

Target:

19/09/2026

May be correct localization.

Target:

09/19/2026

May be correct for another locale.

Target:

19/06/2026

Real error.

Review both value and format.

Step 10: verify times

Time can vary by:

• 12-hour / 24-hour format;
• AM/PM;
• time zone;
• daylight saving;
• locale punctuation.

Source:

17:30

Target:

5:30 PM

Equivalent.

Source:

17:30 UTC

Target:

5:30 PM

Time zone disappeared.

The number comparison may partly pass.

Meaning did not.

Time-zone labels are semantic units

Do not treat:

• UTC;
• GMT;
• SGT;
• CET;
• EDT

as decorative abbreviations.

A missing zone can change deadline interpretation.

Step 11: verify ranges

Source:

10–20 mm

Target:

10–20 mm

Fine.

Potential errors:

• 10–2;
• 10–200;
• 20–10;
• 10 mm–20 cm.

Review:

• both endpoints;
• order;
• unit;
• dash type where style matters.

Inequalities

Source:

≤ 5 mg

Target:

≥ 5 mg

Number identical.

Comparator reversed.

A numeric-token-only check may miss this.

QA should also consider symbols where possible.

High-risk review should inspect:

• <;
• >;
• ≤;
• ≥;
• ±;
• ≈.

These are meaning-bearing.

Step 12: verify negative values

Source:

−5 °C

Target:

5 °C

Negative sign disappeared.

This can affect:

• temperature;
• financial loss;
• coordinates;
• engineering tolerance.

Minus signs are easy to miss visually.

Check them deliberately.

Unicode minus versus hyphen

A source may use:

• hyphen-minus -;
• mathematical minus −.

Tools may normalize or compare differently.

Human readers should focus on value.

Formatting systems may require correct symbol.

Step 13: verify plus/minus tolerances

Source:

10 ± 0.2 mm

Target:

10 ± 2 mm

One decimal disappeared.

The tolerance increased tenfold.

This is high-risk technical content.

Automated token comparison should flag difference.

Human reviewer should understand tolerance structure.

Step 14: verify model numbers and identifiers separately

Not every number is a quantity.

Examples:

• Model X500;
• ISO 9001;
• Clause 7.2;
• Part 123-456;
• Version 4.8.1.

Do not localize identifiers unless policy says so.

A number checker can help preserve them, but identifiers may contain:

• letters;
• hyphens;
• periods;
• slashes.

Pattern QA may be stronger than pure numeric comparison.

Worked example 3: version number

Source:

Version 4.10

Target:

Version 4.1

A human may treat trailing zero as insignificant mathematically.

Software versions may not.

4.10 can be a distinct release from 4.1.

Numbers are not always mathematics.

Context defines identity.

Step 15: verify clause and section references

Source:

See Section 4.2.

Target:

See Section 4.3.

Could be:

• error;
• intentional because target document numbering differs.

If target layout changes numbering, cross-reference system may update automatically.

Do not “correct” without understanding document structure.

Automated cross-references versus typed references

A DOCX cross-reference field may be dynamic.

A plain typed number is static.

The CAT tool may expose them differently.

Round-trip testing can reveal whether target references update correctly.

Step 16: verify phone numbers

Phone numbers include:

• country code;
• area code;
• extension;
• spacing.

Translators should usually preserve identity while adapting formatting only under explicit policy.

Dropping one digit makes contact impossible.

Use dedicated identity-preservation rules where important.

Step 17: verify account and financial identifiers

Examples:

• IBAN;
• bank account number;
• invoice number;
• transaction ID.

These are not quantities.

Do not reformat casually.

One changed digit can send money or records to the wrong destination.

Treat identifiers as protected data.

Step 18: verify statistical values

Statistical documents include:

• p-values;
• confidence intervals;
• sample sizes;
• ratios;
• odds ratios;
• percentages;
• standard deviations.

A smooth sentence can hide a wrong value.

Use number QA plus subject-matter review.

Example: p-value

Source:

p < 0.05

Target:

p > 0.05

Numeric value same.

Statistical meaning reversed.

Again, symbol QA matters.

Step 19: number checks in tables

Tables create dense numeric risk.

Problems include:

• cell shift;
• row mismatch;
• column mismatch;
• missing value;
• duplicated value.

A segment-level number checker may see all numbers but not detect that two values swapped columns.

Visual table review is still needed.

Table totals

If translation process changes formatting, verify:

• subtotal;
• total;
• percentage sum;
• footnote linkage.

Do not recalculate unless authorized, but obvious inconsistencies should be raised.

Step 20: number checks in charts

Charts may contain:

• axis labels;
• legends;
• data labels;
• percentages.

Text extraction may not expose every visual element.

Preview or DTP review is necessary.

A CAT QA pass cannot check what never entered the translation environment.

Step 21: use numeric QA during post-editing

Machine translation can copy numbers correctly most of the time.

“Most” is not enough for high-risk values.

Run deterministic number checks after MT post-editing.

This is one of the best combinations:

• AI for language;
• rules for exact data.

Step 22: use number checks after global edits

Find-and-replace can accidentally alter numeric strings.

Example:

Replacing “5” with “five” globally might affect:

• version 5;
• model X5;
• 50;
• 15.

After global operations, rerun numeric QA.

Step 23: use number checks after review

Reviewers can introduce numeric errors too.

They may:

• retype sentence;
• normalize date format;
• change unit;
• copy wrong value.

Final QA must run after the final substantive edits, not only before review.

Instant QA versus final number QA

Some TMS systems can flag numeric issues when a segment is confirmed.

That is useful.

It catches cheap mistakes early.

But run full-project QA before delivery because:

• later edits happen;
• ignored warnings accumulate;
• cross-file patterns matter.

Failure mode 1: translator assumes numbers copy themselves

Target contains wrong value.

Repair:

• never treat number preservation as automatic.

Failure mode 2: locale formatting flagged as error

Translator wastes time.

Repair:

• configure number formats and separators.

Failure mode 3: intentional conversion ignored

QA shows many mismatches.

Repair:

• document conversion policy;
• verify mathematically.

Failure mode 4: unit changes but value does not

Meaning wrong.

Repair:

• verify value-unit pair.

Failure mode 5: same number, wrong comparator

Basic number check passes.

Repair:

• inspect inequalities and signs.

Failure mode 6: model/version number “simplified”

Identifier changes.

Repair:

• treat identifiers as strings, not quantities.

Failure mode 7: date ambiguity

Translator chooses wrong day/month order.

Repair:

• resolve source convention before localization.

Failure mode 8: reviewer introduces wrong number

Pre-review QA was clean.

Repair:

• rerun after review.

Failure mode 9: table values swap columns

All numbers present.

Meaning wrong.

Repair:

• visual table review.

Failure mode 10: percent sign disappears

Number remains.

Meaning changes.

Repair:

• verify symbols and units.

A number-risk hierarchy

Very high risk

• medicine dosage;
• financial amount;
• safety threshold;
• legal deadline;
• engineering tolerance.

High risk

• percentages;
• dates;
• times;
• model identifiers;
• account references.

Medium risk

• ordinary counts;