Publishing with AI in five languages: what actually breaks, and how you catch it before the reader does

Publishing in five languages now costs what publishing in one used to. AI transcreation — copy reworked for each market, not literal translation — has removed the economic barrier that kept Italian SMEs inside their own language border. This site has been doing it for months: every /risorse article ships simultaneously in Italian, English, French, Spanish and Dutch, produced by an AI pipeline. The 31 published before this one are all there, in five versions each.

Which lets us write something almost nobody writes: here is the defect log. Not hypotheses — the things that actually broke, how we found them and what we changed. Five classes, and the fifth is the one no proofreader would ever have caught, because the text was perfect.

Five things that broke, and how we found them

The shared trait, before the detail: not one was caught before publication. All of them surfaced afterwards, article by article, with no sampling and no termbase locked on the legal terms. That is the process gap the rest of this article fills.

1. The verb that turns a fact into an accusation

A neutral Italian sentence about a real court case, naming the parties, arrived in French with an intensified, editorialising choice of verb: the sense slid from statement of fact to something very close to an accusation. No language error, no ungrammatical sentence — a register drift on a subject where register is the substance.

It is also the highest-volume class we observed: that same article needed three transcreation fixes in French alone, and another one on the construction sector needed four in Dutch. The combination that produces them is always the same — legal or regulatory subject matter plus adaptive translation: transcreation makes the text feel natural in the target language, and “natural”, in a sentence describing a dispute, often means “sharper”.

2. The identical error in all five languages

One article described the EU AI Act's prohibitions as applying to the public sector only. That is wrong — and because the error sat upstream of the per-locale pass, in the shared premise, transcreation propagated it faithfully: wrong in the same way in five languages, at the same moment. The correct scope of the prohibitions is in the dedicated piece on what changes (and what does not) with the EU AI Act for SMEs.

It is not a linguistic class, and that is exactly why it earns its own line: QA has to verify the claim, not the translation of the claim. Five native reviewers hand you back five “matches”, and the premise is still false in all five. Linguistic redundancy is not factual redundancy.

3. The dates no language actually writes that way

The datelines were not coming out in the format each language really uses: day/month order, separators and month-name conventions differ across the five. It is a mechanical defect, not a linguistic one, but it travels on the same pipeline and is every bit as visible as a mistranslation: a Dutch reader who sees a date written the Italian way does not think “formatting bug”, they think the site is not really theirs.

4. No signal that the text had been corrected — this one is closed

None of the defects above carried a revision marker the reader could see: anyone who had read the wrong version had no way of knowing it had since been put right. This item is already resolved and in production: corrected articles now display a visible revision date. It is the only entry on this list that is a completed mitigation rather than an open gap, and it is also the cheapest to copy.

5. The copy is right, it is the code that is wrong

This is the best one, and the only class where the text is correct and the defect is in the code. Two home page components were styling the acronym in the heading with a literal replacement: they searched for the string “AI” and wrapped it in a span to accent it. Transcreation had done its job well — French and Spanish correctly say “IA” — so the search found nothing, replaced nothing, and the two locales rendered a flat heading.

The point is how it fails: silently, and in a silence that slips past every safeguard already in place. No error. No missing translation key — so a key-symmetry test passes, because no key is missing: the rendering differs. And no proofread catches it, because the text is right. It stayed in production until a design change touched that line for unrelated reasons. The fix is trivial: a whole-word match on the union of the locale forms — the regular expression that recognises both AI and IA as standalone words, applied to the already-escaped heading. But the fix is not the lesson.

The real lesson: when you fix a pattern, hunt the pattern — not the file

The two components had an identical defect. The first was fixed a whole cycle before the second was even noticed: the repair had been applied where the bug was found, not everywhere the pattern lived. Result: an identical defect, alive, in two languages, surviving an extra round for no reason at all. A thirty-second grep on the literal replacement would have closed both at once.

This generalises well beyond the case. Any token a view searches for literally and that changes shape from language to language is a candidate for the same silent failure: acronyms (AI/IA/KI), Spanish inverted punctuation, currency symbols, honorifics. If your code compares a source-language string, that comparison is false in at least one of the languages you publish in — and nobody is going to tell you.

The rule we took from it, and apply: a pattern defect is not closed on the file, it is closed on the repository. Before the fix, the grep. Every time.

MQM: the taxonomy that turns “have someone reread it” into a checklist

The localisation industry already has a name for every one of these things, and having one changes how you work. MQM (Multidimensional Quality Metrics) is the standard taxonomy of translation errors, curated by the body that maintains the framework: it organises defects into seven dimensions — Accuracy, Fluency, Terminology, Style, Locale conventions, Verity, Design — each at three severity levels (minor, major, critical), per the scoring models published by the framework. It is the structure underneath ISO 5060:2024 (translation quality evaluation) and ISO 11669:2024 (translation projects), and an explanatory guide from a language services provider walks through the whole apparatus.

Our log maps onto it with almost embarrassing precision. The French case is Accuracy/Mistranslation, high severity because the subject was a real, named case. The scope error on the AI Act is a Verity defect — the category that exists precisely for false statements about the world — which becomes an Accuracy one as well once transcreated. The dates are Locale conventions. The heading without its graphic accent is Design. This mapping, to say it once, is our reading of our own defects — not a result published by anyone.

Why does naming things matter? Because a checklist is built on categories, not on good intentions. “Have someone reread it” is not a process: it has no exit criteria, it produces no data, it does not tell the reader what to look for. “Check the seven dimensions across the three severity levels, and log what you find” does.

Back-translation: it is not round-trip translation

One widespread confusion to close straight away, because it manufactures false confidence. Round-trip translation — feeding the translated text back into the machine to bring it home to Italian and see whether it “comes back” — is a smoke test on model quality, not a QA method. Back-translation is something else: an independent linguist, who has never seen the original, retranslates the localised text into the source language, and the client compares the two versions looking for shifts in meaning. The distinction is definitional: the practical guide of a localisation provider is built on this point, and the glossary entry of a large language services group defines it the same way.

It is the method indicated for regulated content — contracts, legal texts, safety-relevant material: precisely the category our two worst cases fall into. And it works where proofreading fails, for a mechanical reason: it checks conceptual equivalence, not fluency. The intensified verb in the French case was beautifully fluent; it was the concept that had moved, and in a column next to the original a shift like that is visible to the naked eye.

A three-tier glossary, enforced before the reviewer

The safeguard we should have had first is the dullest one: a locked termbase. Good practice for regulated content splits it into three tiers, described by a localisation platform's blog:

• brand and product terms — the names that are never translated, in any language;
• technical and domain terms, including regulatory and legal terminology, fixed language by language so the model cannot invent a plausible but wrong equivalent;
• forbidden or high-risk terms — superseded designations, other companies' trademarks, legally treacherous phrasings.

The detail that makes the difference, though, is the order of execution. The glossary has to run as a check on every segment before or during transcreation, with violations flagged before the text ever reaches a reviewer: that is the flow described by the 2026 guide to terminology enforcement workflows from an industry vendor, which also adds the part almost everyone skips: a termbase needs a named owner and a review schedule, because a glossary that is correct at launch degrades on its own over time. On our two worst classes, a list of forbidden phrasings — verbs that impute conduct, scope claims of the “applies only to sector X” kind — would have caught both before publication.

The 10% sample, weighted by risk instead of flat

Current practice among localisation operators is not to reread everything: roughly 10% of delivered volume is sampled for a post-hoc native review, as the localisation QA guide of a testing provider describes. The part that really counts is the second half: that 10% is a baseline, not a rule, and on high-risk content — legal, regulatory, safety — it has to be raised, up to full review.

Mature LQA programmes structure distinct QA tiers — spot check, standard review, full in-context review — tied to the risk tolerance of each content type: that is the setup in a practical guide to language quality assurance from a localisation services provider. From which the uncomfortable consequence: a uniform sampling percentage across every topic is itself a design defect.

Locale formats and pseudolocalisation: the class you can automate away

Dates, numbers and currencies are flagged insistently as the single most frequent class of locale bug: hand-written formats break silently in every language that is not the source one — month and day swapped, decimal and thousands separators changing, the currency symbol on the wrong side. The standard fix is to stop writing strings and move to locale-aware formatters, verified in CI, as the 2026 guide to i18n formatting from a localisation platform sets out. It is the safeguard that makes our third class impossible: there is no way to get wrong a format you never write.

Upstream of that sits a technique worth knowing even if you do not build software: pseudolocalisation, explained by a translation management platform's guide — you render the interface with fake strings, lengthened and accented, before a real translation exists, so the points that break show up while you are still building. It is designed for interface strings more than editorial text: it covers your application, not your articles.

Three traps our pipeline is built to catch

Three conditions that today, across the 31 publications preceding this one and all five languages, come out consistent. We are listing them anyway: they are the kind of thing that breaks without a sound, and a safeguard gets built before it is needed.

• Per-language file ordering is not guaranteed. The Dutch file of article descriptions lists its entries in a different order from the Italian. No problem today — but any automation that assumes “line N in Italian corresponds to line N in Dutch” is wrong by construction. You align by key, never by position.
• French writes percentages with a space before the sign — “180 %”, “70 %” — where Italian writes “180%”. Consequence: a regex written while looking at the Italian text skips French without flagging anything. It does not loudly find zero matches: it finds fewer, and everything looks fine. Every sweep over multilingual text has to be written on the union of the conventions.
• Our colophon check is evaluated per language. Correct as it stands — but it means a citation present in Italian and dropped in Dutch would split the claim about sources across two languages without tripping anything global. The safeguard exists because that asymmetry is possible.

The checklist, ordered by risk rather than charged at a flat rate

Translated into operations, for anyone publishing multilingual AI-generated content:

1. Classify by risk, before anything else. Articles on legal, tax or regulatory matters, or naming real cases and institutions, do not get the same treatment as a how-to guide: a back-translation-style check on the sentences that assert something, ideally a full native read.
2. Lock terminology per language before transcreation, with the list of forbidden phrasings — verbs that attribute conduct, scope claims — and violations flagged before the text reaches a reviewer.
3. Separate fact-checking the claim from verifying the translation. The fact-check belongs on the Italian source, before the fan-out. Open the link and read the cited page against the claim: the worst class of error is the one where a verifiable figure and an invented one sit in the same sentence, where the “does it cite real sources?” spot check passes and the claim stays false. How to declare all of this to the reader is the subject of the piece on what to tell customers about your use of AI.
4. Sample 10% with native review, raising the share on risky content. That upward deviation is what makes sampling useful rather than reassuring.
5. Put dates, numbers and currencies through a locale-aware formatter, checked at build time. Zero hand-written date strings per language.
6. Grep the pattern, not the file. Every time you fix a structural defect — a comparison against a source string, a positional assumption, a regex tuned to Italian — search the whole codebase for the pattern before closing it. It is the cheapest check on the list and the one that cost us most to skip.
7. Put a visible revision date on corrected articles. Ours is already in production: it is how language quality programmes declare a problem instead of quietly patching it, and for a reader it is the difference between a site that corrects itself and one hoping nobody notices.

None of these five classes is an argument against AI transcreation: they are the running cost of a capability that until recently did not exist at this price, and that cost is paid in process, not in translators. The right question before publishing is not “is the translation good?”, it is “what would break without anyone telling me?” — because the defects that matter are there: not in the wrong sentence, but in the right one, rendered by code that speaks a single language.

The external sources cited here are localisation service vendor guides, i18n platform blogs and the documentation of the body that curates the MQM taxonomy, consulted on 29 July 2026: they are not scientific research or peer-reviewed literature. The ISO 5060:2024 and ISO 11669:2024 standards are cited by name on the basis of those guides, without consulting the text of the standards. The mapping of the defects observed on our pipeline onto the dimensions of the MQM framework is our own analysis, not a result cited by third parties. In the sources consulted there is no measured defect rate for AI transcreation on legal or regulatory copy: no such percentage is reported here, and be wary of anyone offering you one.