Converting Japanese Text to Romaji With AI

A model asked to romanise Japanese will produce shashin in one paragraph and syasin in another, and both are standard. They come from different romanisation systems, the choice between them is never surfaced, and a document that switches halfway is the normal outcome of an unspecified prompt.

Three systems, not two

Japanese has three romanisation systems in real use, and they are not variants of each other — they are built on different premises.

• Hepburn writes what an English speaker would need in order to approximate the sound. It is what appears on station signs, on passports and in most English-language publishing about Japan. し is shi, ち is chi, つ is tsu, ふ is fu.
• Kunrei-shiki writes the kana table regularly, one row at a time, so that the grammar stays visible. It was made the government’s standard for domestic use by a Japanese Cabinet notification in 1954 and is standardised internationally as ISO 3602. し is si, ち is ti, つ is tu, ふ is hu.
• Nihon-shiki is the strictest character-level mapping, older than both, and the only one that is fully reversible because it distinguishes kana that modern Japanese pronounces identically — ぢ as di against じ as zi, づ as du against ず as zu.

The reason Kunrei looks wrong to English speakers is exactly the reason it exists. In Kunrei the verb 立つ conjugates tat-anai, tat-imasu, tat-u, tat-e — one stem throughout. In Hepburn the same verb is tat-anai, tach-imasu, tats-u, tat-e, and the stem appears to change three times. Hepburn is better for a reader who will never study the grammar; Kunrei is better for anyone who will. Neither is a mistake, which is why a model produces both.

The kana that give the system away

You do not need to read the source to work out which system an output followed. A handful of syllables differ, and one of them will appear in any paragraph of Japanese.

kana   Hepburn   Kunrei   Nihon-shiki
し      shi       si       si
ち      chi       ti       ti
つ      tsu       tu       tu
ふ      fu        hu       hu
じ      ji        zi       zi
ぢ      ji        zi       di
づ      zu        zu       du
しゃ    sha       sya      sya
ちょ    cho       tyo      tyo
じゅ    ju        zyu      zyu
を      o         o        wo

So 写真 is shashin or syasin; 地図 is chizu or tizu; 富士山 is Fujisan or Huzisan. If your output contains both shi and tu, the model mixed systems inside one response, which is the failure this page exists to prevent.

There is a second split inside Hepburn itself. Traditional Hepburn writes the moraic ん as m before b, m and p: 新橋 becomes Shimbashi, 群馬 becomes Gumma. Revised (modified) Hepburn keeps n everywhere and uses an apostrophe before a vowel or y to mark a syllable boundary: Shinbashi, Gunma, and 心配 as shinpai against 単位 as tan’i. Both spellings of Shimbashi are printed on real signage in Tokyo. If you are matching against an existing dataset, pick the variant that dataset uses rather than the one you prefer.

The long vowel problem

This is where the choice becomes consequential rather than cosmetic. Japanese distinguishes short and long vowels, and 東京 has two long o sounds. There are four ways to write that and they all appear in production data.

• Macron — Tōkyō. Modified Hepburn’s convention, correct, and a non-ASCII character that half of the systems downstream will mangle.
• Circumflex — Tôkyô. Kunrei-shiki and ISO 3602 use this rather than the macron.
• Doubled or appended vowel — Toukyou, which reflects the kana spelling とうきょう exactly and is what Japanese input methods produce. Reversible, ASCII, and unreadable to an English speaker.
• Dropped — Tokyo. What the city is called in English, what a passport prints, and lossy: 小野 and 大野 both become Ono.

Japanese passports use Hepburn without macrons, with one documented escape: a long o may be written OH on request, so 大野 can be issued as OHNO rather than ONO. That means a person’s legal Latin name may not be derivable from their kanji at all, and if you are matching a model’s romanisation against a passport you will get false negatives that no prompt can fix. Store the name as given and romanise only for display.

Pinning one system for a whole document

Consistency across a document is a different requirement from correctness on one word, and it needs the rule stated as a rule rather than demonstrated by an example.

SYSTEM
Romanise Japanese into modified Hepburn. Apply these without exception:

- し=shi ち=chi つ=tsu ふ=fu じ=ji しゃ=sha ちょ=cho じゅ=ju
- ん is always "n". Before a vowel or y, write n' (tan'i, shin'you).
- Long vowels use macrons: aa=a, ii=ii, uu=u, ei=ei, ou=o, oo=o.
- Sokuon っ doubles the following consonant; before ch, write "tch"
  (matcha, not macha).
- Particles は, へ, を are romanised by pronunciation: wa, e, o.
- Capitalise sentence-initially and for proper nouns only.
- Do not translate. Do not gloss. Output romaji only.

1. Run one paragraph containing し, つ and a long o. Those three cover most of the disagreement surface.
2. Grep the output for si, tu, hu and ti as whole syllables. A hit means Kunrei leaked in and the run is mixed.
3. Decide the macron question before you run a batch, not after. If any consumer is ASCII-only, ask for the macron form and strip it at the boundary, so the lossy version is derived from the complete one rather than the other way round.
4. Normalise to NFC. ō can arrive as U+014D or as o plus combining macron U+0304, and the two will not compare equal.
5. For a long document, romanise in chunks with the same system prompt on every chunk rather than in one call. Consistency comes from the instruction, not from the context.

Particles, and where transliteration stops

The particle rule in that prompt is the one place where romanisation stops being a character mapping and starts requiring the model to parse. The kana は is ha as a syllable and wa as the topic particle; へ is he and e; を is effectively only ever the object particle. Deciding which one you are looking at means knowing the grammar of the sentence, which is why a lookup table cannot do this and a model can.

It is also the best diagnostic you have. Feed a sentence containing は as a particle. If the output says wa, the model understood the sentence. If it says ha, it is transliterating character by character, and everything else it produces should be treated as mechanical rather than informed.

The same parsing requirement is why word boundaries appear at all. Japanese is written without spaces, so any romaji with spaces in it reflects a segmentation decision the model made — the same decision that splitting Japanese text for retrieval depends on, and a common source of disagreement between two runs on the same input. Mixed-script source text makes it harder still; Japanese mixes kanji, two kana syllabaries and Latin in one sentence as a matter of ordinary orthography.