Korean Romanization Systems and Which One AI Uses

Busan and Pusan are the same city. Jeonju and Chŏnju are the same city. You can tell which system produced a piece of romanised Korean from two characters, and once you can, the inconsistency in a model’s output stops being mysterious.

Two living systems

Revised Romanization of Korean was promulgated by South Korea’s Ministry of Culture and Tourism in July 2000 and is the official system there. It is diacritic-free and ASCII-only by design — that was an explicit goal, because the system it replaced needed characters that did not survive the internet of the 1990s. Road signs, government documents and Korean tourism material all use it.

McCune-Reischauer, published in 1939, is still the standard in Korean studies, in library cataloguing (the ALA-LC tables are a McCune-Reischauer variant), and in a modified official form in North Korea. It uses a breve over two vowels and an apostrophe to mark aspirated consonants. It is better at telling you how a word is pronounced and worse at surviving a database.

Both are correct, both are current, and a model has read enormous amounts of both. An academic paper in its context pulls output towards McCune-Reischauer; a travel itinerary pulls it towards Revised Romanization; a long document gets some of each.

The same words in both

Hangul   Revised Romanization   McCune-Reischauer
부산      Busan                  Pusan
대구      Daegu                  Taegu
광주      Gwangju                Kwangju
전주      Jeonju                 Chonju      (o with breve)
인천      Incheon                Inch'on     (o with breve)
독도      Dokdo                  Tokto
김치      Gimchi                 Kimch'i
한글      Hangeul                Han'gul     (u with breve)

The pattern is systematic rather than arbitrary. Two families of difference account for all of it.

• The lenis stops. Korean ㄱ ㄷ ㅂ ㅈ are not the same as English g d b j nor the same as k t p ch; they sit between, and they sound closer to one or the other depending on position. Revised Romanization writes them g d b j always, trading phonetic accuracy for a stable spelling. McCune-Reischauer writes them k t p ch at the start of a word and g d b j between vowels, so the same syllable is spelled differently depending on where it lands.
• The two vowels Latin does not have. ㅓ is eo in Revised Romanization and an o with a breve in McCune-Reischauer; ㅡ is eu against a u with a breve. Every disagreement about a vowel comes back to these two.

McCune-Reischauer also needs the apostrophe to distinguish aspirated ㅋ ㅌ ㅍ ㅊ from plain ㄱ ㄷ ㅂ ㅈ, so ch’o and cho are different syllables. Revised Romanization uses separate letters — k t p ch for the aspirates, g d b j for the plain ones — which is why it needs no apostrophe and why its k means something different from McCune-Reischauer’s k. That is the trap: the same letter in the two systems denotes different sounds, so a mixed output is not merely inconsistent, it is wrong.

Telling them apart at a glance

Three tests, in order of reliability:

• A breve over an o or a u, or an apostrophe after k, t, p or ch, means McCune-Reischauer. Nothing else produces those.
• The letter pairs eo and eu mean Revised Romanization. They are the system’s signature and they are frequent enough to appear in almost any paragraph.
• Neither present, in a text long enough that one should be, means the source is following common English usage rather than any system — which is very often the correct answer for names.

Beware a fourth case that looks like a system and is not: McCune-Reischauer with the diacritics stripped. This is extremely common, because the breve does not survive an ASCII pipeline, and it produces Chonju and Hangul — strings that are neither system, that merge ㅓ with ㅗ and ㅡ with ㅜ, and that cannot be converted back. If you see McCune-Reischauer-shaped output with no diacritics anywhere, assume a normalisation step ate them rather than that the model omitted them.

Why personal names follow neither

Applying Revised Romanization strictly to 이, 박, 정 and 최 yields I, Bak, Jeong and Choe. Almost nobody with those surnames writes them that way. Lee, Park, Jung or Chung, and Choi are what appear on passports, business cards and academic papers, and the romanisation rules themselves acknowledge this: existing spellings of personal names and of company names are permitted to stand.

So a model that outputs Park for 박 has not failed to apply the standard; it has applied the exception, and the exception is the rule that matters for anything involving a person. A pipeline that “corrects” Park to Bak is generating a spelling that will match nothing. The same caution applies to the order of the parts: Korean puts the family name first, and a pipeline that reorders it while romanising has changed the name twice.

There is a second name-specific rule that catches people out. Revised Romanization normally reflects pronunciation including sound change across syllable boundaries — 신라 is Silla and not Sinla, 종로 is Jongno and not Jongro, because the consonants assimilate. For given names, the convention is the opposite: the syllables are romanised as written rather than as assimilated, so 빛나 is Bitna, and an optional hyphen (Bit-na) may be used to show where the syllables divide. A model applying place-name logic to a personal name produces a spelling the person does not use.

Choosing one, and making it stick

Pick Revised Romanization unless you have a specific reason not to. It is ASCII, it is current, it is what South Korean official material uses, and it does not lose information to a normalisation step. Choose McCune-Reischauer only if you are matching an existing library catalogue or an academic corpus that already uses it — and if you do, budget for the diacritics surviving your entire stack, because a McCune-Reischauer field that loses its breves is worse than either system.

Then state it as a table, not as a name:

SYSTEM
Romanise Korean using Revised Romanization (2000). Fixed mappings:

  ㅓ=eo  ㅡ=eu  ㅐ=ae  ㅔ=e  ㅚ=oe  ㅢ=ui
  ㄱ=g  ㄷ=d  ㅂ=b  ㅈ=j   ㅋ=k  ㅌ=t  ㅍ=p  ㅊ=ch

Never use a breve or an apostrophe. ASCII output only.
Place names: apply sound assimilation (Silla, Jongno).
Given names: do NOT assimilate across syllables (Bitna, not Binna).
Surnames: use the conventional English spelling where one is
established (Lee, Park, Kim, Choi, Jung), not the strict form.

One encoding matter sits underneath all of this and will bite before any romanisation question does. Hangul exists in Unicode both as precomposed syllable blocks and as sequences of individual jamo, the two look identical, and they do not compare equal — why two identical-looking Korean strings fail an equality check covers it. Normalise to NFC on the way in, before you romanise anything, or you will spend a day debugging a transliteration problem that is really a normalisation problem.