You send a 200-page equipment manual out for Spanish translation. The prose comes back well written, the layout holds, the terminology is consistent. Then a reviewer in Madrid opens the specification table and finds this:
Longitud máxima: 406.5 mm
Every word is Spanish. The number is not. In Spanish, as in German, that measurement is written 406,5 mm — the fraction separator is a comma, and thousands are grouped with a period. A figure an English source writes as 1,234.50 becomes 1.234,50.
Why this is more than a cosmetic issue
An untranslated separator is not simply untidy. Because the two conventions use the same two characters in opposite roles, the same string can carry two readings that differ by a factor of a thousand.
Consider 1.234 in a torque specification. An English-speaking engineer reads roughly one and a quarter. A German-speaking technician reads one thousand two hundred thirty-four. Nothing in the string itself resolves the ambiguity — only the reader's assumption about which convention the document follows does, and a document that mixes both conventions removes even that.
For technical, medical, and regulatory content, this moves out of the realm of style. ISO 80000-1 and the SI conventions treat the decimal marker as a property of the language and locale, and reviewers in regulated industries routinely reject deliverables over it. It is also one of the few defects a client notices immediately, because it is visible without reading a single sentence of the translation.
Why generic translation tools leave numbers alone
Raw machine translation is inconsistent rather than wrong
Most machine translation and large language model output treats a number as material to reproduce, not to convert. That is a defensible default — the alternative risks corrupting part numbers — but it means numbers arrive in the target document still written the source's way.
The more troublesome outcome is partial conversion. A language model handling a long document in sections may localize a measurement inside a sentence, leave the identical measurement in a table cell untouched, and produce a third form somewhere else. The result is a document where the same specification appears in two or three different notations, which is harder for a reviewer to clean up than a document that is uniformly unconverted.
Traditional CAT tools treat it as configuration and review
The problem is well known in the translation industry, and established CAT tools do address it. Trados Studio, for example, offers auto-localization of numbers and currency. It is instructive to read what its documentation says about the conditions.
The behavior has to be switched on: if translation-memory recognition settings are not enabled for these items, RWS notes, auto-localization does not occur and numbers "are treated as normal, translatable words." Which separators get applied is itself configuration — the formats Studio offers during auto-substitution are, per the documentation, "based on your Windows Regional Settings," and a source format outside the defaults has to be added as a custom recognizer before it is seen at all. And when a translation-memory match is available, Studio reuses the format stored in that match rather than the target language's default. RWS presents that as consistency with your existing translation units, which it is — but it also means, in the documentation's own words, that "different placeable formats can be used in the same translation file."
Source-side recognition has limits of its own: the documentation gives the example of a pattern such as x-xxx,xx being recognized as three separate numbers rather than one, precisely because of the separators it contains. And verifying the result is a separate step again, through the QA Checker number checks — whose own documentation uses exactly this article's example: rendering the English 5,000 as the German 50.000 is wrong, and 5.000 is the correct conversion.
None of this is a criticism of the tool. It is evidence of how much configuration and human review the conventional answer requires — and of how easily a busy project skips it.
The part that makes automation genuinely difficult
The naive fix is a search and replace: turn every period between digits into a comma. That breaks the document, because not every number states a quantity. Many numbers identify something, and an identifier must survive translation character for character:
- Section and clause numbers:
7.4.2 - Version and standard references:
DisplayPort 1.4,IEC 60204-1 - Thread, grade, and part designations:
M5x40,316L - Dates, page numbers, phone numbers, IP addresses
Convert those and you have replaced a cosmetic defect with a factual error — a citation pointing at the wrong clause is worse than a decimal point in the wrong style.
The distinction is not always obvious from the characters alone. pH 7.0-7.8 states a quantity and should be localized. DisplayPort 1.4 names a version and should not. Both are a digit, a period, and a digit. A dimension written as a chain, such as Ø30x1.5 mm, states quantities and its separators do move — while the visually similar M30x1.5 is a thread designation and stays as it is. Deciding correctly needs an understanding of what the number is doing in its sentence, which is why pattern matching alone tends to either miss cases or damage them.
And the target convention is not a single thing
There is one further trap worth knowing about before you specify a requirement. "Uses a comma for decimals" does not tell you how that language groups thousands.
Spanish and German group with a period, giving 1.234,50. But French, Norwegian, Swedish, Finnish, Polish, and Russian group with a space: the same figure is 1 234,50, and twelve thousand one hundred ninety-two is 12 192, not 12.192. Roughly half of the comma-decimal languages fall on each side of that split, and the decimal comma gives you no clue which. A conversion that gets the decimal marker right and the grouping wrong is still a conversion a native reviewer will flag.
How SimplifyAI handles numbers during translation
SimplifyAI derives the numeric conventions from the target language of your job, using the separator conventions that language actually follows rather than assuming the pattern of the more common European languages. When you have not specified a source language, the document is analyzed to establish what convention the source itself is written in — which matters, because a German source translated into Spanish already writes numbers the way Spanish does, and needs no conversion at all.
Numbers then get two passes rather than one, because the two halves of the problem need different things.
The judgment goes to the model. Deciding that pH 7.0-7.8 states a quantity while DisplayPort 1.4 names a version takes an understanding of what the figure is doing in its sentence, and no pattern supplies that. So the translation is given the target language's conventions along with worked examples, and asked to apply them to quantities only.
The floor is set by deterministic checks. A model asked to convert numbers across a long document is reliable but not uniformly so — it will localize a measurement in a sentence and leave the same measurement in a table cell. Quantities left in the source's convention are therefore brought into line afterwards, and separators the model changed where the two languages already agree are put back. That second case is the one most tools never consider: when your source and target write numbers the same way, the correct action is to change nothing, and a figure quietly rewritten there is a new defect rather than a fix.
What that means in the delivered file:
- Measurements, counts, prices, and percentages are written the target language's way, including figures that occupy a table cell on their own with no surrounding sentence to give them away.
- Section numbers, version numbers, part and thread designations, dates, and other identifiers are left exactly as the source has them.
- Digits inside protected tokens and code placeholders are never touched.
- Every digit is preserved. Only what sits between digits can change, so a converted figure carries the same value as the source.
- The same specification is written the same way throughout the document, rather than one way in the table and another in the paragraph that cites it.
Two honest limits are worth stating. First, the quantity-or-identifier judgment is a judgment, and unusual notations in specialized fields can still be read the wrong way — so numeric spot-checks belong in your review pass, particularly in the first job for a new document family. Second, grouping conventions that vary by domain even within one language, as they do in some financial and scientific writing, may need a house style decision that no general default can make for you.
Where this fits in the workflow
- Upload your InDesign, Word, or PDF source file and select the target language.
- The system analyzes the document and prepares the translation, including a reviewable terminology plan.
- Translation runs with the target language's numeric conventions applied to quantities, and the result is checked against those conventions before it is written back.
- Preview or export the result, and spot-check the specification tables before delivery.
Number formatting is one of the details that separates a translation that reads as native from one that reads as translated. If you produce technical documentation for European markets, upload a source file with a specification table and check how the figures come back.