Japanese to Chinese technical files: separate protected identifiers from reader-facing text, record decisions and compare a published semiconductor case.
View the file review example ↓Separate Japanese labels from protected identifiers
A Japanese file can contain text to translate and identifiers to preserve on the same line. Define these separately before drafting the Chinese version. A protected code is not a reason to leave the surrounding explanation untranslated.
From reading to a project
Separate Japanese labels from protected identifiers
Japanese identifier register · made-up example
- Source label and identifier
- 文書番号：JP-DEMO-01
- Chinese draft · for review
- 文件编号：JP-DEMO-01
- Protected item
- JP-DEMO-01 · match the source character for character
- Owner decision
- Confirm the Chinese label, identifier rule and where the rule applies
Review status: questions to confirm
Classify each item
Separate model codes and identifiers from Japanese headings, descriptions and instructions.
Keep a reason and an owner
Record why an item is protected, the required spelling and who can approve a change.
Check both text and references
Compare protected items across the Chinese file set without omitting the surrounding reader-facing translation.
Related published experience
Torex SemiconductorJapanese → Chinese
Japanese-to-Chinese documentation for a listed Japanese semiconductor manufacturer.
The Torex project records Japanese-to-Chinese semiconductor documentation in 2011. It does not identify the illustrated code or establish software or datasheet delivery.
Send the source edition and actual source language, protected model codes or identifiers, approved Chinese names and any existing exception list. Mark where each rule applies and who can approve it; confirm the Chinese script, review scope, return files and deadline.
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.
Agree the protected-term list, its owner, the reason for each entry and the review process in the project brief. Confirm separately whether the file format and tools support automated checks; code-coupled items need the relevant engineering owner’s input.
For Chinese company and product names, use the names and protected-terms register to distinguish approved names from provisional translations.
| 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. | Agree the list, its owner and review process; confirm separately whether the format and tools support automated checks. |
| 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. | Ask the relevant engineering owner to identify code-coupled items and confirm the handling rule. |