Five languages, one name: multilingual check-in in ENTRIX

A self check-in kiosk in Bangkok serves guests from everywhere. ENTRIX runs its guest flow and staff dashboard in five languages: English, Thai, Chinese, Russian and Burmese. The guest picks a language before anything else, and that choice travels with the session through to the check-in email that carries their door code.

The interface half is discipline more than technology. Every user-facing string goes through one translation layer, and a new string is added to all five locale files in the same change, never to English first with the rest left for later. A parity test enforces it. With English as the fallback, a missing key does not fail loudly; it quietly shows English to a Thai guest, which is exactly the failure a test has to catch. Russian carries the extra plural forms its grammar needs. Layout is checked at phone width in at least one long-string language, because Thai and Burmese run considerably longer than English and a row that fits in one can wrap or clip in another.

The check-in email follows the same rule with one deliberate exception. The template's structure and styling are identical in every language, and only its text nodes are swapped. Content a property wrote itself, such as amenity names or local recommendations, is not machine-translated on its behalf. Inventing translations for a property's own words is not ours to do.

The harder half is names. The first thing a guest types is a name and a booking reference, and ENTRIX has to decide whether that name belongs to the reservation. The booking may have been made through an online travel agency in romanised form, the guest may type a nickname, and the passport may use another convention again.

ENTRIX resolves a name to a set of candidate forms, not a single string, and two names match if any form of one equals any form of the other. Thai gets its own transliteration engine, because Thai romanisation depends on syllable structure: vowels that are not written and consonants that change value depending on where they fall. Cyrillic, Greek, Korean Hangul and Devanagari share a second engine. There is rarely one correct romanisation, so competing systems are emitted in parallel: a Cyrillic letter can become kh or h, a Korean surname Lee, Yi or Rhee. The number of variants per name is capped, so a name full of ambiguous characters produces a bounded set rather than an explosion.

Before the second engine existed, a guest booked as Aleksandr Ivanov typing his name in Cyrillic scored well below any usable threshold, and a Korean name typed in Hangul scored zero, meaning the comparison had nothing to work with at all. Those are real people who could not check in, and they are why the engine exists.

Widening a matcher is only safe with an asymmetry in mind. A false reject costs a guest a walk to reception. A false accept hands a stranger a door code. So matches are graded. Only a provable match accepts automatically. A strict subset, such as a missing middle name, asks the guest to confirm on screen, because a person is standing there to ask. Anything merely similar is refused at the default setting, and two reservations matching the same name are never auto-resolved; picking one would be a guess with a key attached. Every widening ships with negative controls proving that different people still fail.

How strict to be is a property's decision. Each property sets how close a typed name must be and whether the check blocks or only records, and both the reservation name and the name read off the document are stored, with any variance flagged to staff. Five languages on the screen is the visible part of multilingual check-in. The name engine underneath is what makes it safe.