DEV Community

James Carter
James Carter

Posted on

How a Transliteration Engine Thinks: From "namaste" to Devanagari

Most typing tools for Hindi ask you to learn a new keyboard. A transliteration tool takes the opposite bet: you keep typing on the English keyboard you already know, and the software converts your Roman letters into Devanagari script as you go.

That sounds simple until you look at the mapping problem:

  • Ambiguity everywhere. A single Roman letter can map to several Devanagari characters depending on context. "a" at the start of a word is not the same as "a" in the middle.
  • Digraphs are units. "kh", "gh", "chh", "aa", "ee" have to be consumed as single sounds, which means the parser should match greedily, longest first.
  • Predictability beats cleverness. Users build a mental model of the tool. If "namaste" converts one way today, it must convert the same way tomorrow, or trust evaporates.

The design rule that falls out of all this: the user should never have to think about the machine. They type the way they chat — Hinglish, mixed with English, full of shortcuts — and the script quietly takes care of itself.

I work on these problems around a small free tool that does this live in the browser. Type in Hinglish, get Devanagari out, copy it anywhere. No sign-up, no new keyboard, no translation changing your words — just your own sentences in the script they belong to.

If you build for multilingual users, I would argue transliteration is the most underrated UX pattern on the web: it meets people at the keyboard they already have.

Top comments (0)