Avoid Keyboard Event-Related Bugs In Browser-Based Transliteration — Smashing Magazine

Transliteration on Mobile: A Different Approach to an Old Problem

Browser-based transliteration—typing English characters to produce non-English text—depends heavily on how browsers handle keyboard events. Users of tools like Google Input Tools expect to type a phonetic approximation (for instance, "pahana" in Sinhala) and see the corresponding characters (“පහන”) appear in real time. But on Android's Chrome browser, this kind of conversion can fail unexpectedly. The solution may be to stop relying on keyboard events altogether.

The Core Issue

For non-English scripts, the standard implementation approach is straightforward: intercept the keyboard event, prevent the default character insertion, and insert the mapped character instead. On desktop browsers, this works without issue. On Android's Chrome, that same logic breaks down—keystrokes are either not captured properly or the event handling does not behave as expected.

One popular demonstration of this is Google Input Tools. When typing "pahana" into its text box on a desktop browser, the expected Sinhala result appears correctly. On Chrome for Android, the same input may remain as English text, revealing a fundamental weakness in the event-capturing approach.

Two Implementation Strategies

For a simple input method where one non-English character maps directly to one English key (e.g., "p" → "ප"), there are two distinct ways to implement the behavior:

Method 1: Prevent default and capture keyboard events. This method involves two actions: first, stop the browser's default behavior (which would type the English character), and second, in the keydown, keypress, or keyup event handler, insert the intended non-English character. The browser bug in Chrome for Android undermines this logic.

Method 2: Listen to input changes and modify content dynamically. This approach avoids keyboard events entirely. The script simply watches the text box content—for instance, via the input event—and after each change, it checks the latest character. If that character matches a key in the mapping, it deletes that character and replaces it with the corresponding non-English one.

Comparing Both Methods in Practice

Testing both methods with a one-to-one mapping—where "p", "h", and "n" map directly to "ප", "හ", and "න"—shows a clear difference. Typing "phn" into a text box using Method 1 yields correct Sinhala output on a laptop but fails on the Chrome mobile browser. Method 2, the event-free approach, handles both environments without fault.

This outcome suggests that bypassing keyboard event capturing entirely can circumvent the mobile browser's handling issues, producing a more reliable transliteration experience.

Dealing with Text Prediction

Even with the alternate method, mobile users may still encounter unexpected behavior. The culprit is often the soft keyboard's text prediction. Disabling features like text prediction, auto-suggestions, and auto-capitalization can resolve the issue. Some keyboards—for instance, SwiftKey on certain devices—do not permit disabling prediction, so switching to another keyboard such as Gboard may be necessary.

Implementation Notes

Method 1 Details

The first method uses the onkeydown event on the text area. When the event fires, a function prevents the default action and delegates to a handler that inserts the appropriate mapped character, based on the pressed key.

Method 2 Details

The second method adds an oninput event listener to the text area—using input instead of change is critical because the latter only fires when the element loses focus, which is too late for live transliteration. Each time the event fires, the handler examines the updated text content, identifies the most recently typed character, and performs a replacement according to a predefined mapping between English and non-English characters.

This method is not limited to keyboards. Any change to the text box content—whether from a keyboard, voice input, or autofill—triggers the same logic, making it a more robust foundation for transliteration features.

Considerations for Complex Scripts

For many languages, a one-to-one mapping is insufficient. Scripts like Sinhala feature independent vowels, consonants, dependent vowel signs, and other complex combinations that often require more elaborate input sequences. The Unicode Consortium provides comprehensive documentation and code charts for these scripts; understanding the intricacies of a target language's character set is essential before building a text input application for it.