When AI Should Transliterate a Name Instead of Translating It

“Use judgment for proper nouns” is the instruction most translation prompts contain, and it is not an instruction. It cannot be tested, it cannot be reviewed, and it produces a document where 白 is Bai on page one and White on page four. The decision has three branches and all of them are mechanical.

The default is transliterate, and it is not close

A proper noun refers. That is the whole of what it does. 王小光 is a particular person, and the fact that 光 also means “light” is as irrelevant to the reference as the fact that the English surname Baker once described a job. Translating the meaning produces a string that refers to nobody.

The failure is not hypothetical and it is not confined to exotic cases. Bulk translation pipelines produce Mr White for 白先生, and Forest for the surname 林, and Flower for the Vietnamese given name Hoa, and they do it precisely because those characters are also ordinary words with high-probability English equivalents. A model translating a sentence is doing the same operation on every token; a name is only protected if something tells the model it is a name.

So the default has to be stated as a default, not assumed. Every instruction of the form “translate this document” should carry “transliterate personal names; never translate a name’s meaning” alongside it, because the model is not otherwise distinguishing the categories.

There is one narrow exception inside the personal-name branch, and it is worth stating so that it does not get generalised: descriptive epithets attached to historical figures are translated by convention. Иван Грозный is Ivan the Terrible, not Ivan Grozny; Guillaume le Conquérant is William the Conqueror. The epithet is a description that happens to be attached to a name, and English has settled forms for these. This does not license translating any other meaningful element of any other name.

Branch one: an established exonym exists

The first question is not “translate or transliterate”. It is “does English already have a name for this thing?” If it does, that name wins over both operations, and it is very often derived from neither.

• 长江 is Yangtze in English. Transliterating gives Changjiang; translating gives Long River. The established English name is a third thing, taken from a different Chinese name for a section of the river.
• Den Haag is The Hague. München is Munich. Wien is Vienna. None of these is a transliteration and only one is close to a translation.
• Deutschland is Germany, from a Latin name for a people that the Germans do not use for themselves.

The important property of this branch is that it is a lookup, not a derivation. There is no rule that produces Yangtze from 长江. Either you know the exonym or you do not, and a model is very good at the well-known ones and confidently wrong at the obscure ones — it will produce a plausible English-sounding name for a small town that has no English name at all.

That asymmetry is the design constraint. The lookup branch has to be allowed to fail, and the failure has to be visible, or the model will invent an exonym rather than fall through to transliteration.

Branch two: the generic half of a place name

Toponyms usually have two parts: a specific, which identifies, and a generic, which says what kind of feature it is. The convention used in geographical-names work, including by the UN Group of Experts on Geographical Names, is to transliterate the specific and translate the generic.

天安门广场   Tiananmen Square    specific transliterated, generic translated
黄河         Yellow River        both translated (established exonym)
富士山       Mount Fuji          specific transliterated, generic translated
Mont Blanc   Mont Blanc          no translation: established as-is in English
Rio Grande   Rio Grande          likewise
서울역        Seoul Station       specific transliterated, generic translated

Note that 富士山 romanises as Fujisan in full, and English says Mount Fuji — which produces the well-known redundancy where a speaker says “Mount Fujisan”. That redundancy is the visible symptom of the generic being handled twice, and it is exactly what a model does when the rule is not stated: it translates the generic and also transliterates it.

The counterexamples in the table matter as much as the examples. Mont Blanc and Rio Grande both have translatable generics and neither is translated, because branch one fires first — English has an established form and it retains the foreign generic. The branches are ordered, and getting the order wrong produces White Mountain.

Branch three: a registered name is a fact

Organisations and products have official names in other languages, and those names are neither transliterations nor translations. They are decisions somebody made and registered.

• 可口可乐 is Coca-Cola. The Chinese name is itself a transliteration of the English, chosen for its meaning, and the correct English rendering is to return to the original — not Kekou Kele, not the literal reading of the characters.
• 微信 is WeChat. Not Weixin (the transliteration) and not micro-message (the translation). The company chose an English name and it is unrelated to both.
• 华为 is Huawei, where the transliteration happens to be the registered name — which is why this branch cannot be skipped by assuming it never coincides with branch one. Note that the transliteration itself still has to be pinned to a standard, since pinyin has a toned and a toneless form and only one of them belongs in a company name.

A model knows the large ones and guesses the rest, and the guess is usually a competent transliteration presented with the same confidence as a known fact. For a product handling company names at scale, this is the branch that needs an external lookup — your own table of registered names — with the model used only to fall through when the lookup misses.

The rule, as prompt text

The argument of this page is that the above is a procedure, and a procedure belongs in the prompt as a procedure. Here is the whole of it in a form a model can follow and a reviewer can check:

PROPER NOUN HANDLING — apply in this order, stop at the first match.

1. If an established English name exists for this entity, use it.
   (Yangtze, Munich, The Hague, Mount Fuji.)
   If you are not confident one exists, do NOT invent one. Go to 3.

2. If the name is a place name with a generic element (river, mountain,
   square, station, province), transliterate the specific part and
   translate the generic part. Do not do both to the same element.

3. Otherwise transliterate. Never translate the meaning of a personal
   name, a surname, or a brand, even where the characters are also
   ordinary words.

4. For an organisation or product, if you know its official English
   name, use that instead of steps 1-3. If you do not, transliterate.

For every proper noun, return which branch you used and whether you
were confident, so a reviewer can check the ones that were guesses:
  [ { "source": "...", "output": "...", "branch": 1, "confident": true } ]

The last instruction is the part that makes the rest of it worth having. “Use judgment” produces output you cannot audit; a branch number and a confidence flag produce output where the twelve rows that need a human are identifiable out of four thousand that do not. The rule is not better than judgment because it is smarter. It is better because it leaves a trace.

Two related decisions are worth settling in the same prompt while you are there: which romanisation standard the transliteration in branch three should follow, since that is under-specified in every script this cluster covers, and whether the family name comes first, which is a separate question that the same pipeline gets wrong for the same reason — nobody told it.