Some terms should stay in the source language — product names, regulated identifiers, certain UI. Getting the do-not-translate list right prevents a whole class of embarrassing and expensive errors.
- The errors a DNT list prevents
- What belongs on it — and the nuance for each
- Making the list actually work in production
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 a do-not-translate (DNT) list is how you scope them out before they happen.
The list is cheap to make and expensive to omit. Most teams build one only after the first incident.
What belongs on it — and the nuance for each
Brand and product names. Usually kept, but confirm per market: some names are transliterated in scripts like Chinese or Japanese, and some are changed entirely because the original means something unfortunate locally. "Do not translate" and "do not adapt" are different instructions — say which you mean.
Regulated identifiers. Substance names in some contexts, model numbers, standard references (ISO 10218, 21 CFR 820), UDI codes. These are keys, not prose. Translating them breaks traceability.
Code-coupled strings. Placeholders, variables, and UI text that the software matches literally. If a string is compared against a fixed value somewhere in the code, translating it is a bug. Engineering, not the linguist, has to flag these.
Third-party quotations and legal citations. Often must be reproduced verbatim, sometimes with a translation supplied alongside rather than in place of the original.
Making the list actually work in production
A DNT list only helps if it is machine-enforceable. Deliver it as data the CAT tool can lock — protected segments the translator cannot alter — not as a note in an email that a busy linguist skims once. The point is to make the wrong action impossible, not merely discouraged.
Version it with the content. Product names change, new regulated terms appear, UI gets refactored. A DNT list that was right at launch and never touched since will, within a year, be protecting terms that no longer exist and missing ones that now matter.
And record the reason next to each entry. "Keep in English" tells the next person nothing; "UI string matched in code — do not touch" tells them exactly why, and stops someone removing it in a future cleanup because it looked arbitrary.