A thoroughly nonsensical jingle has been circulating on the Chinese internet for years: "Two kun jin kao (锟斤拷) in hand, shouting tang tang tang (烫烫烫); a thousand tun tun tun (屯屯屯) underfoot, laughing at a world of nuo nuo nuo (锘锘锘)." According to public references including the Wikipedia entry on Chinese garbled text, the Baidu Baike article on kun jin kao and Moegirlpedia, the four lines actually correspond to three different kinds of encoding accident. An early Guokr discussion supplies an even better punchline: one contributor remembered a first-year programming class where a program copied straight from a textbook printed a row of tang tang tang, and, convinced the machine was overheating and sounding an alarm, he bent down and pulled out the plug. The joke has been passed around technical circles for well over a decade and later turned up as an in-joke in game dialogue. For translators it is funny with a sting in it: sometimes a file was not mistranslated at all, but was already broken before it reached your desk.
Each line has its own origin. Kun jin kao comes from character set conversion. When Unicode cannot represent a character it substitutes U+FFFD, the replacement character, encoded in UTF-8 as EF BF BD. When that byte sequence repeats and is then read two bytes at a time as GBK, it becomes kun (EFBF), jin (BDEF) and kao (BFBD). The crucial word is lossy: once the replacement character appears, the original bytes have been thrown away, and no amount of later conversion brings them back. Tang tang tang and tun tun tun come from somewhere else entirely. In debug mode, Visual C++ fills uninitialised stack memory with 0xCC and heap memory with 0xCD; in GBK, 0xCCCC happens to be tang and 0xCDCD is tun. Early command-line programs drew window borders with the box-drawing character 0xCD from code page 437, so under code page 936 a border turned into a long run of tun tun tun. The last line, nuo nuo nuo, is the UTF-8 byte order mark (EF BB BF) at the start of a file being read as GBK: the first two bytes decode as nuo, so http shows up as nuo xian ttp and public as nuo feng ulic. Three unrelated faults bundled into one mock-heroic picture — that is where the humour lives.
This is not a mistranslation; the source file is already damaged
Taking garbled text for an inaccurate translation is a common misunderstanding. Translation deals with meaning and wording; garbled text is what happens when bytes are read under the wrong interpretation. The same EF BF BD is one replacement character in UTF-8 and three Chinese characters in GBK. Nobody translated anything wrongly; the reading rule was wrong from the first step. The lossy kind is worse: U+FFFD means the original character was discarded during conversion, so the characters on screen look like content but are really just the shape of a hole. Guessing the missing word back from context at that point is no different from inventing a line the source never had. The first thing a translator should do is not repair but classify: is this an encoding problem, a font problem or an extraction problem? Then go back to the source and ask for a clean, copyable file with a stated encoding, rather than continuing to work on damaged text. One comforting detail: this class of accident has nothing to do with language ability, and no amount of experience protects anyone from an attachment saved in the wrong format.
Empty boxes, tofu and question marks are not the same thing
Blank spaces on a screen come in several kinds. A character missing from a font appears as a hollow square, called tofu in the trade; changing or embedding the font fixes it, and the underlying text data is intact. Wrong characters, missing strokes or confusing 己 with 已 after extracting text from a PDF or a scan belong to the recognition stage and must be checked against a clear original. A screen full of kun jin kao is byte-level damage and can only be fixed by going back to the source. The remedies are completely different, and mixing them up produces two familiar wastes of effort: retendering an entire document when only a font was missing, and dropping a plausible-looking character into a hole where the data is already gone. Classify first, then act — it is the least visible and most valuable habit in this line of work.
Certificate work is where one casual correction does the most damage
Jokes aside, the mood changes when this lands on an everyday job. When a name, certificate number, issuing authority, expiry date or seal inscription breaks at a garbled or missing character, the worst response is to complete it with the most common reading. One radical, one digit, one hyphen can make a whole packet of papers contradict itself, and the reason given for returning it is often just "does not match the original". The safe routine is to mark the spot as pending verification exactly as it stands, keep a separate list of queries, and confirm each item against the source. If a clear original genuinely cannot be obtained, state the situation rather than deciding on the source's behalf. It is the same rule as the locked name list and the refusal to guess in the company article, seen from the translator's desk instead of the submission counter. After enough certificate work, a near-superstitious caution sets in: the more obvious it looks that a character "must be this one", the more important it is to go back and look at the original.
Four habits that cost almost no time
In the end they are all dull methods. Save an untouched copy of every incoming file and never overwrite the original. Confirm the encoding and the fonts, deliver in UTF-8 without a byte order mark, and say so separately if another encoding has to be kept. Keep the terminology list and the name list as a separate plain-text file, stored apart from the working document. Before delivery, read names, numbers, dates and amounts with your own eyes in the plainest possible view, rather than trusting a neatly laid-out finished page. The industry article is about a whole set of texts having to line up when higher-value products are exported; this one is about the precondition, that the file has to be complete in the first place. The jingle has stayed funny for more than a decade because everyone who works with text has met a screen full of tang tang tang one afternoon or another. Once you have laughed, the useful question is: for this source file, who actually checked the original for you?