VaakBoard: a precision input system for Sanskrit

The language problem

Devanagari is not an alphabet in the Latin sense. A consonant carries an inherent vowel, a following vowel replaces it with a sign, two consonants can fuse into a conjunct, and anusvara and visarga attach without any of that machinery. A keyboard that only swaps one letter for another cannot get these right.

On a phone the problem is harder: phonetics, transliteration, the rules of the script and fast lookup all have to work inside the limits of a small keyboard.

The linguistic model

The engine treats typing as composition, not substitution. Text is normalised, tokenised by greedy longest match (three letters, then two, then one) and composed using the script's rules: a consonant is emitted with a virama; a following vowel replaces the virama with its matra; the inherent a just removes it. Anything that is not language input passes through untouched: spaces, digits, punctuation, emoji, URLs, e-mail addresses, @mentions and #tags.

• Two input schemes: a Harvard-Kyoto style Latin scheme (case-sensitive) and full IAST with diacritics.
• Reverse transliteration from Devanagari back to IAST, with lossless IAST round trips covered by tests.

Input architecture

The keyboard interface contains no linguistic logic. The engine is a stack of small layers that can change independently.

• Input normalisation: built
• Scheme tables (data only): built
• Tokenise and compose: built
• Reverse transliteration to IAST: built
• Language detection: not built
• Lexicon and dictionary: not built in this engine
• Suggestions: not built
• Correction and undo: not built

UX principles

Every feature has to make typing faster, more accurate, easier, more natural or more accessible. If it does not, it does not ship.

• Predictable: the same input always gives the same output.
• Recoverable: a user can always get back to what they typed.
• Offline first and private: core transliteration stays on the device, and typed text is not sent anywhere.
• English stays excellent: multilingual must not cost normal keyboard behaviour.
• Few settings, grouped by the questions people ask.

Implementation

The engine and the web demo are in this repository and share the same code. The engine has a test corpus for Sanskrit words in both schemes, IAST normalisation, scheme detection, reverse transliteration, round trips, punctuation, digits, emoji, URLs and long input, and it checks the examples the page itself displays.

The iOS keyboard is a Swift keyboard extension with a custom trie and an offline lexicon. Its source is not in this repository, so this study does not describe it beyond that.

Open problems, stated plainly

• No language detection. English typed in Latin mode is transliterated, so Hello becomes Devanagari. Mixed-language typing is the main open problem.
• No Roman Hindi rules. Without schwa deletion, bharat gives भरत rather than भारत. That needs a lexicon, not a rule.
• A vowel after a vowel is kept as hiatus, so boa gives बोअ.
• The Latin scheme was changed to follow common conventions (sh as श, S as ष). If the iOS app used the older mapping, the two must be aligned deliberately.

Current, building, planned