Why Translators Switch Off Number Checks - and What Slips Through

A number checker flags a translation, the target looks right, and the delivery deadline is close. After enough alerts like that, a translator may switch the check off. The risk is that the same setting that silences harmless formatting warnings can also hide a changed code, date, or amount.

Number verification is useful, but it doesn’t understand every way a language can express quantity. A QA tool compares features in source and target text; it doesn’t automatically know whether a digit string is a currency, a product code, a date, or an ordinal. That gap explains both the false alarms and the real errors that slip through.

What a number check actually compares¶

A translation QA number check is an automated comparison of numeric features in source and target segments. Many checks look for digits, punctuation, and patterns that appear to represent numbers. They can flag a target when a source value seems to be missing, added, or changed.

The check is a warning system, not a verdict. A warning says that the tool found a difference worth examining. It doesn’t establish that the translation is wrong, and a clean report doesn’t prove that every quantity means the same thing in both languages.

Consider a source segment containing a model or encoding name. Translatehouse’s pofilter numeric-check example flags a target in which “Windows-1252” has become “Windows-1254”. The changed digits are part of an identifier, so the alert points to a real discrepancy, not a localized style choice.

The Translatehouse example reports: “The number 1252 does not appear in the translation.”

The example shows the basic strength of a numeric checker: it can draw attention to a changed value that a reader might overlook while concentrating on language. A translator still has to decide what the digits represent and whether the change is intentional.

A checker can also compare the wrong thing. Suppose the source contains a number in digits and the target spells the quantity out in words. A digits-only comparison sees a missing number, though a human reader may find the meaning intact. Translatehouse explicitly notes that an alert “Might not be a problem if 2 has been written in full”. The wording matters: the translation needs review, not automatic rejection.

A useful way to read alerts is to separate three questions:

1. Did the underlying value change? Check the quantity, identifier, date, or code itself.
2. Did only the presentation change? Compare separators, spacing, symbol placement, and whether the target spells out the number.
3. Does the value still play the same role? A digit can be a count in one sentence and a reference number in another.

That distinction prevents two opposite mistakes: accepting a genuine value change as harmless formatting, and editing a correct localized expression just to satisfy a mechanical comparison. For more on how different automated checks fit together, see automated QA checks in translation.

Why false positives pile up¶

False positives happen because numerical meaning is more flexible than a string of digits. Languages and locales can change how numbers look, and translators sometimes change how a quantity is expressed. A checker that expects the same characters on both sides may count those valid changes as errors.

A correct number can look different¶

The Unicode CLDR specification distinguishes numeric numbering systems, which use a set of digits, from algorithmic systems, which represent quantities through rules. Western and Thai digits are examples of numeric systems; Chinese numerals can be algorithmic. A comparison based only on matching characters can’t reliably establish that two forms represent the same quantity. See the CLDR number specification.

The same issue arises when digits become words. An English target may express a small number in words to fit the style of a sentence. A checker that extracts numerals from the source and target can report the source value as missing, even if the target communicates it clearly.

Ordinal forms create a related problem. A source may use a digit with an ordinal ending, while the target writes an ordinal word or uses a different grammatical form. The characters aren’t identical, but the sentence can still refer to the same position in a sequence.

Compact forms can cause another mismatch. Microsoft documents expressions such as “123K” as legitimate numeric presentations. A checker that expects the full digit sequence may treat the compact form as an omitted value or an extra letter, even when the target follows the intended style. Microsoft’s overview of locale-sensitive number formatting discusses these forms.

Separators depend on locale¶

The punctuation inside a number isn’t universal. CLDR defines decimal and grouping symbols as locale-specific, and Microsoft notes that commas, dots, Arabic decimal separators, apostrophes, and middle dots can serve as decimal separators depending on locale or context. A checker built around one convention can report a valid target as inconsistent. The CLDR numbers specification and Microsoft’s number-formatting guidance describe these differences.

Grouping marks vary too. Microsoft’s guidance describes three-digit grouping as common in European languages, four-digit grouping in China, Japan, and Korea, and a South Asian pattern such as 1,00,00,000. Spaces, commas, and dots can all separate groups. A source and target can therefore display the same value with different punctuation and grouping.

A regional example makes the problem concrete. Microsoft notes that DIN 1333 specifies a space separator from five digits in Germany, while common German usage often uses a dot as the grouping separator. A checker tied to one presentation can flag the other, even though the reader can interpret both in context. The applicable house style still matters: a format can be recognizable and yet not match the client’s instructions.

Negative values and currencies add further variation. A negative number can use a leading hyphen-minus or accounting parentheses. A currency symbol can move before or after the amount, and spacing can change. Microsoft’s examples include “€ -1.234,56” in the Netherlands and “-1 234,56 €” in France. The figures in those examples illustrate locale-specific formatting; they aren’t instructions to copy one country’s style into another.

Alerts can reflect source defects¶

A mismatch doesn’t always mean the target introduced an error. The source itself may contain a typo, repeated punctuation, or an inconsistent value. Translatehouse’s pofilter documentation includes a punctuation example in which the source has two dots and the translation has corrected them. The guide advises leaving the corrected translation as it is and reporting the source issue.

That example concerns punctuation rather than a numeric change, but the review principle also matters for numbers. A translator shouldn’t reproduce a source error merely to make the two segments look alike. The right action is to confirm the intended value, document the issue, and raise it with the client or project lead when the source doesn’t provide enough context.

What slips through when checks are disabled¶

Turning off a noisy check can make the report easier to read, but it also removes a prompt to inspect numbers. The missed errors aren’t limited to obvious typos. A digit can be copied incorrectly, a decimal mark can shift, or a reference number can change while the surrounding prose remains fluent.

Changed codes and identifiers¶

Codes, product names, standards, and file formats often contain digits that should remain exact. The Windows-1252 to Windows-1254 change in the pofilter example shows why number checks are valuable even when a translation looks polished. A misplaced digit in an identifier can point readers to a different item.

A translator may also assume that a number was intentionally adapted when it should have been copied unchanged. That assumption is risky for model numbers, document references, version labels, and similar strings. The surrounding words may not reveal the mistake, which is exactly why an independent comparison helps.

Shifted values and signs¶

A digit can be dropped, repeated, or replaced during typing or editing. A decimal separator can be mistaken for a grouping mark, and a negative sign can disappear. A number checker may catch some of these changes, but the alert still needs a person to verify what the value means in that sentence.

For money, checking the digits alone isn’t enough. The reviewer needs to read the amount together with its currency and sign. A correct-looking amount with a missing minus sign or the wrong currency can change the meaning even if most of the number matches.

Dates that appear equivalent but aren’t¶

Dates are particularly easy to misread because the same digits can be arranged differently across locales. CLDR treats date formats as locale data and supports distinct patterns, so literal character matching isn’t enough to establish that two date strings represent the same day. Reviewers need to parse the date as a date and check its parts in context. The CLDR date specification explains how date patterns vary by locale.

A target date can look different from the source without changing the day. The opposite can happen too: familiar-looking digits can point to a different month or day if a reviewer assumes the source convention carries over. A number check may flag the formatting difference, miss the interpretation problem, or do both in a single segment.

One translator in the RWS community forum described the conflict this way: “I get more false positives than actual positives.”

The forum post is an individual report, not evidence about how often number checks fail across the profession. The useful lesson is narrower: when an alert feels noisy, translators may stop reading it as a prompt and start treating it as clutter.

The same forum poster also said that the check had caught a couple of errors that would have been embarrassing if missed. That detail illustrates the trade-off. A tool can produce many unhelpful warnings and still catch a genuine problem that matters.

When number verification is worth keeping¶

Number verification earns its place when a project contains values that need to survive translation exactly. The check can draw attention to differences; a reviewer then decides whether the alert reflects a changed value, a valid transformation, or an issue in the source.

High-value use cases include codes, identifiers, measurements, totals, dates, amounts, quantities, and numbered references. A reviewer should still consider the document’s purpose. A change in a casual marketing sentence may carry different consequences from a changed value in a contract or procedure.

The European Commission describes translation quality control as including bilingual revision for accuracy and completeness, with separate monolingual review for clarity, tone, and suitability for the audience. An automated number warning is one layer, not a substitute for either type of review. The Commission’s translation quality guidance explains that approach.

Risk should shape how much attention a team gives each alert. The Commission says the consequences of errors depend on document type and notes that legal errors can have legal or procedural consequences. The Commission recommends more extensive checks for higher-risk texts, and identifies time pressure, available resources, and translator expertise as factors when assessing error likelihood. These points support a practical distinction: a low-risk text can receive a lighter review, while a value with legal, procedural, or operational consequences deserves closer attention.

The European Commission says fit-for-purpose translation depends on context, drafting, and language-specific conventions as well as linguistic accuracy. Read the Commission’s quality guidance as a reminder that an alert needs contextual judgment.

For a number checker, context answers questions that a string comparison can’t. Is the digit part of a code or an amount? Is a currency symbol attached to the right figure? Does the target express an ordinal, a count, or a date? Can the target style guide explain the changed format?

A team that works with QA alerts can record the outcome in a simple review category:

The table is a decision aid, not a promise that every alert will fit one neat category. Some alerts involve more than one problem. A target can use a valid local format and still contain the wrong value.

For teams comparing manual and automated checks, the TEP model and multi-step translation QA offers context on how review stages can work together. Numeric checks support that process; they don’t replace a bilingual read-through.

How to review dates, currencies, and measurements¶

A number review works best when the reviewer checks meaning first and formatting second. Start with the item that must remain true, then look at how the target expresses it.

1. Identify what the number represents. Decide whether the digits are a quantity, date, amount, code, measurement, percentage, or reference. A code usually needs exact preservation; a quantity may allow words or a localized format.
2. Compare the value, not just the characters. Check every relevant part, including sign, decimal fraction, and unit or currency. Don’t assume that a familiar-looking string has the same meaning in both locales.
3. Check the target locale and style guide. Confirm the expected decimal and grouping marks, spacing, sign position, and currency placement. Locale conventions explain what can be valid; the project style guide determines what the deliverable should use.
4. Read the number in its sentence. Make sure the target assigns the value to the same person, item, date, or action as the source. A matching number in the wrong sentence can still be an error.
5. Classify the alert and record the decision. Mark it as a value change, formatting difference, intentional wording change, or source problem. Keep an explanation for exceptions that another reviewer may question.
6. Escalate unresolved source issues. Ask the client or project lead when the source is ambiguous or internally inconsistent. Don’t guess at a value with operational or legal consequences.

When can a team accept a number alert?¶

A team can accept an alert when a reviewer has confirmed that the target preserves the intended value and follows the project’s requirements. A number written in words may be correct; a different separator may follow the target locale; a date may use a different pattern while retaining the same date.

Acceptance needs a reason, not a reflex. “Looks fine” doesn’t tell the next reviewer whether someone checked the value, the format, and the context. A short note such as “same amount, target currency style” makes the decision easier to verify.

When should a team escalate instead of guessing?¶

Escalate when the source offers competing values, a code differs between two places, or the intended date or amount can’t be confirmed from context. A translator can preserve an obvious typo and report it, but shouldn’t invent the value that the author might have intended.

A source defect can be more dangerous than a visible mismatch because it invites a translator to silently repair content without authorization. The pofilter documentation’s example of corrected source punctuation shows the value of separating the translation decision from the source report. A reviewer can fix an evident translation problem while making the source issue visible to the person responsible for it.

How should teams reduce false alarms without losing useful warnings?¶

Start by setting the correct target locale and applying the client’s formatting rules. A checker configured for a different convention may generate alerts that teach reviewers to ignore the report. Locale-aware settings reduce avoidable noise, though they can’t resolve every context-dependent case.

Next, filter or classify alerts rather than disabling the whole check. A change in a code deserves attention; a known transformation from digits to words may not. Teams can use past decisions to clarify review expectations, but should avoid broad exceptions that suppress every number in a segment or document.

In the RWS forum post, the translator estimated, “95% of the errors were false positives and I would ignore.”

That percentage is the poster’s self-reported estimate, not a measured industry statistic. Treating it as a general rate would be misleading. The relevant warning is that a user who believes most alerts are false may ignore the one that matters, even if the check has previously caught real errors.

A team should review its own alert patterns instead of borrowing a percentage from one person’s experience. If repeated warnings come from a known formatting convention, check the locale or rule configuration. If alerts flag unexplained changes to codes, amounts, or dates, retain them and investigate.

Common mistakes that make number QA less useful¶

The most damaging mistake is treating every alert as a confirmed translation error. A checker reports a difference; it doesn’t know whether that difference is valid. Changing a correct target to match the source’s punctuation can make the result less suitable for its audience.

The reverse mistake is just as costly: treating every alert as noise. The RWS post captures both sides of that choice: the translator reported a high volume of false positives and also said the check had caught errors that would have been embarrassing to miss. Turning the warning off entirely removes both the noise and the useful catch.

A few habits make review more reliable:

• Don’t compare punctuation in isolation. Establish the locale and style guide before deciding whether a separator is wrong.
• Don’t assume every digit string is a quantity. Codes, identifiers, version labels, and dates need different checks.
• Don’t assume matching digits prove matching meaning. Check sign, unit, currency, order, and the sentence where the value appears.
• Don’t fix a source defect silently. Record the issue and tell the project lead when the intended value isn’t clear.
• Don’t accept a warning without reading the target sentence. A numeric match can still accompany a meaning error elsewhere in the segment.
• Don’t use a single global exception for every number. A broad suppression can hide a genuine change alongside harmless format differences.

A number check is most helpful when it fits into a wider review workflow. Automated comparison can find a suspicious change; bilingual revision checks accuracy and completeness; monolingual review checks clarity and audience fit. The European Commission describes those review goals in its translation quality guidance.

FAQ¶

Why do translation QA number checks produce false positives?¶

Number checkers often compare visible digit strings rather than interpreting meaning. A number written in words, a localized separator, or a different date format can therefore look like a mismatch even when the target is correct.

What types of number errors can a translation QA checker miss?¶

A checker can miss values written as words, ordinals, compact forms, or another numeral system. It can also fail to detect a changed value if the source and target contain the same digits in different roles.

Should translators disable number verification in CAT tools?¶

Usually, keep number verification available and tune or filter alerts where the tool allows it. Disabling it entirely removes a useful check for changed codes, quantities, dates, and other values.

How should localization teams review dates, currencies, and measurements?¶

Check whether the value and its role are preserved, then confirm that the target follows the requested locale and style guide. Review dates as dates and currencies as amounts with their symbols, spacing, and signs.

How can teams reduce false alarms in translation number checks?¶

Set the target locale and formatting rules, inspect the alert in its sentence, and classify it as a value change, a format difference, or a valid transformation. Keep genuine mismatches visible instead of suppressing the entire check.