Transliterating Russian Names for a Passport or Visa Form

Ask a model to transliterate Дмитрий and you get Dmitry. The passport says DMITRII. Both are right, an airline will accept only one of them, and no prompt makes the first turn into the second by accident.

Two correct answers to one question

There is a spelling used in English prose — in a news article, a scientific paper, a business email — which follows English reading conventions and often follows nothing at all beyond what the person has always written. And there is a spelling printed in the machine-readable zone of a travel document, produced by a fixed table applied by a government system, which nobody chose and which is not intended to be read aloud.

They diverge on the most common letters in Russian given names, so the two forms of a name are rarely close. This is not a case where one system is a slightly stricter version of the other; a person can reasonably not recognise their own name in the passport form.

The prose spelling is what a language model produces, and it produces it for a good reason: it has read English text about Russians, and that text says Dmitry Medvedev and Yulia and Alexei. It has read comparatively little of the transliteration tables. So the model’s default is right for the job it was trained on and wrong for a form.

There is a structural difference between the two documents underneath this, and it catches out forms designed around Western name shapes. A Russian full name has three parts: given name, patronymic (formed from the father’s given name, ending -ovich or -ovna), and surname. The internal passport carries all three. The international passport carries the given name and the surname only. So a form with a “middle name” field will collect the patronymic from a person reading their domestic document, and that patronymic does not appear on the travel document the booking has to match. If the field is optional, leave it empty for travel; if it is required, it must not be concatenated into the name compared against the document.

The table a travel document uses

Machine-readable travel documents follow the specification published by the International Civil Aviation Organization as Doc 9303, which includes a transliteration table for Cyrillic. Russian international passports have used it since the mid-2010s. The letters that differ from what an English reader expects:

е = e     ё = e      ж = zh    й = i      х = kh
ц = ts    ч = ch     ш = sh    щ = shch   ъ = ie
ы = y     ь = (omitted)        э = e      ю = iu     я = ia

Four of those are the whole story. й becomes i and not y. ю becomes iu and not yu. я becomes ia and not ya. The soft sign disappears entirely rather than becoming an apostrophe. Between them they touch most Russian given names and a large share of surnames.

The output is upper case throughout, restricted to the letters A to Z with no diacritics and no apostrophes, because that is what the machine-readable zone can hold.

The same names, both ways

Cyrillic     natural English      travel document
Дмитрий      Dmitry / Dmitri      DMITRII
Юлия         Yulia / Julia        IULIIA
Алексей      Alexei / Alexey      ALEKSEI
Андрей       Andrei / Andrey      ANDREI
Наталья      Natalya / Natalia    NATALIA
Георгий      Georgy               GEORGII
Евгений      Evgeny / Eugene      EVGENII
Захарьин     Zakharin             ZAKHARIN

IULIIA is the one that convinces people the system is broken. It is not: Ю is iu, л is l, и is i, я is ia, so the double i in the middle is two separate letters meeting. The table is applied character by character with no smoothing, which is the property that makes it reproducible and the property that makes it unreadable.

Why it was built to look wrong

The constraints explain the design completely. A travel document table has to be applied identically by every issuing authority, in every Cyrillic-using country, by software with no linguistic knowledge, into a fixed-width ASCII field, and it has to be stable so that the same person gets the same string every time. Readability is not on the list and is actively traded away, because a border system compares strings and does not pronounce them.

It is worth noticing what the table gives up to get that. It is deterministic forwards and ambiguous backwards: е, ё and э all become e, and и and й both become i, so a Latin string cannot be converted back to Cyrillic. That is a deliberate choice and the right one for the purpose — a border system never needs to reconstruct the Cyrillic, because the Cyrillic is printed on the same page. It does mean the passport field is unusable as a source for anything else. You cannot recover the person’s name in Russian from it, and you cannot derive a readable English spelling from it either, because the information that would let you choose between Dmitry and Dmitri is gone.

The natural English spelling optimises for the opposite thing and therefore cannot be mechanical. Alexei against Aleksey, Natalia against Natalya, Eugene against Evgeny — these vary by publication, by the person’s own preference, and by whether the name has an English cognate. That is the space a model is sampling from, and there is no correct answer in it, only conventional ones. The broader landscape of Cyrillic standards is in the comparison of ISO 9, GOST, BGN/PCGN and the national systems.

The specification itself is the thing to check rather than a summary of it — ICAO publishes Doc 9303 in parts, and the transliteration table sits with the material on machine-readable data.

What to do in a form or a booking system

The operative rule is short: never generate a spelling that has to match a document. Copy it.

1. Ask for the Latin name as printed on the document, in its own field, and label the field that way. Do not derive it from a Cyrillic field, ever, no matter how good your table is.
2. Keep a separate display name. That is where a model-generated Dmitry belongs, and it should never be sent to an airline, a visa system or a bank.
3. Do not validate the document field against your own transliteration. It will reject correct input, and the person cannot do anything about it because their passport says what it says.
4. Expect two members of one family to have different Latin surnames. Russian passport transliteration rules have changed more than once, and passports issued in different years were produced under different tables; regulations have allowed a holder to request retention of an earlier spelling on the basis of existing documents, which produces further legitimate variation. Ukraine reformed its own table in 2010 for related administrative reasons, described in the Ukrainian standard and what it replaced.
5. When matching a booking to a document, compare the document field exactly and treat the display name as unusable for matching. A fuzzy match between DMITRII and Dmitry is not a near miss; it is two different fields doing two different jobs.