Some content should stay in the source language — product names, regulated identifiers, code-coupled strings. These are not translation-quality failures but scoping failures, and their cost usually becomes visible only after the first incident.
- The errors a DNT list prevents
- The difficulty is not listing the categories — it is the nuance inside each
- A list that holds up is not the same as a list that got written
The errors a DNT list prevents
Ask a translator to translate everything and they will — including the things that were never meant to move. A product name gets localized into a common noun. A regulated substance identifier gets "helpfully" rendered. A UI string that matches a hard-coded value in the software gets translated, and the button stops working.
None of these are translation-quality failures; they are scope failures. And scope is set before anyone starts translating — by review, the error is already in the product. Most teams discover they needed a do-not-translate list only after the first incident.
The difficulty is not listing the categories — it is the nuance inside each
"What should not be translated" sounds like a simple question. What makes it hard is the exceptions inside every category.
Brand and product names. Seemingly the most obvious to keep, actually the most market-dependent — some names are transliterated by convention in scripts like Chinese or Japanese, and some must be changed entirely because the original means something unfortunate locally. "Do not translate" and "do not adapt" are different instructions, and conflating them produces two kinds of wrong answer.
Regulated identifiers. Model numbers, standard references (ISO 10218, 21 CFR 820), UDI codes are keys, not prose; translating them breaks traceability. The difficulty is the boundary: the same substance name may have to be translated on a label and left alone in a submission field.
Code-coupled strings. This category is one a linguist cannot judge at all — whether a string is compared against a fixed value elsewhere in the software is knowable only from the code side. Identifying it takes cross-functional work, not language skill.
Third-party quotations and legal citations. Often reproduced verbatim, sometimes with a translation supplied alongside rather than in place of the original. Which one applies depends on what governs the document doing the citing.
A list that holds up is not the same as a list that got written
The DNT lists we review fail for the same handful of reasons. A list that exists only in an email or a briefing document depends on every linguist remembering to consult it — someone always misses it. An entry that says only "keep in English" means nothing to the next person and gets deleted in a future cleanup as unexplained legacy. Product names change and new regulated terms appear, so a list that was right at launch and never touched since ends up doing two things at once a year later — protecting terms that no longer exist, and missing the ones that now matter. And code-coupled strings are not something a language team can judge on its own; that category is knowable only from the code side.
The DNT lists we deliver are data the tooling enforces, not prose; every entry carries a reason and an owner; they are reviewed on a cycle tied to product and regulatory changes; and engineering is brought in during compilation specifically to catch code-coupled strings.