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.
| Category | Why it is on the list | The nuance that breaks a flat rule |
|---|---|---|
| Brand and product names | Seemingly the most obvious to keep as-is. | Actually the most market-dependent. Some are transliterated by convention in Chinese or Japanese; some must change entirely because the original means something unfortunate locally. “Do not translate” and “do not adapt” are different instructions. |
| Regulated identifiers | Model numbers, standard references (ISO 10218, 21 CFR 820), UDI codes are keys, not prose — translating them breaks traceability. | The boundary. The same substance name may have to be translated on a label and left alone in a submission field. |
| Code-coupled strings | A string compared against a fixed value elsewhere in the software; translate it and the button stops working. | A linguist cannot judge this at all. It 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 a translation is supplied alongside the original rather than in place of it. Which applies depends on what governs the document doing the citing. |
None of these are translation-quality failures; they are scope failures. Scope is set before anyone starts translating — by review, the error is already in the product.
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.
| Failure | What happens | What we do instead |
|---|---|---|
| It lives in an email or a briefing doc | It depends on every linguist remembering to consult it. Someone always misses it. | The list is data the tooling enforces, not prose. |
| Entries say only “keep in English” | It means nothing to the next person, and gets deleted in a future cleanup as unexplained legacy. | Every entry carries a reason and an owner. |
| Written at launch, never touched | A year later it does two wrong things at once — protecting terms that no longer exist, and missing the ones that now matter. | Reviewed on a cycle tied to product and regulatory changes. |
| The language team decides it alone | Code-coupled strings are invisible from the language side, so they are simply not on the list. | Engineering is brought in during compilation specifically to catch them. |