· via dev.to (home feed)
Unetype trains 0.8B and 4B transliteration models for mode-free mixed-script typing
Unetype says dedicated 0.8B and 4B transliteration models power a keyboard that converts mixed Latin-and-non-Latin sentences in place, preserving code tokens and removing IME mode switching.

Unetype has trained two dedicated transliteration models — one with 0.8 billion parameters and one with 4 billion — to power a mixed-script input method that converts text in place as you type, without switching keyboard modes. In a post published on dev.to on November 7, the team behind the Unetype keyboard explains why existing dictionary-based IMEs and general-purpose chat models could not meet the demands of an interactive input loop.
The friction Unetype is targeting
Mainstream operating systems treat input methods as stateful, single-language modes: at any given moment you are either typing English or typing in Pinyin or Romaji mode, the post argues. Developers who mix Latin-script identifiers such as git rebase or useEffect with Chinese or Japanese phrases end up toggling between modes several times per sentence — or forget to toggle and watch their identifiers get converted into unintended characters. Unetype's premise is that a user should be able to type an entire mixed-script sentence on a standard Latin keyboard and have the whole thing converted where it sits.
Where dictionaries and generic LLMs fall short
The company identifies three engineering constraints. The first is that English and code tokens must survive conversion untouched: a naive converter or a general-purpose model will often try to help by translating or transliterating English words embedded in a phonetic sentence. Unetype's example is the input "wo men jin tian deploy staging branch ba", which must produce "我们今天deploy staging branch吧" — the technical tokens left exactly as typed while the surrounding phonetic spans are converted.
The second is cross-script phonetic ambiguity. Syllables such as ni, de, to, no, kan and shi overlap across Pinyin, Romaji and ordinary English words, so deciding whether "main" is a Git branch name or a phonetic syllable requires full-sentence context rather than matching tokens one at a time against a dictionary.
The third is in-place replacement inside host applications. Rather than shuttling text between a chat window and a separate tab, a single shortcut — Caps Lock, or Option/Alt plus Enter — converts the current draft in the focused input field. The same mechanism can trigger inline features the company calls AI Keyboard Polish Writing, AI Keyboard Translator and AI Text Explainer.
Language coverage and availability
Unetype lists five conversion pairs: Pinyin to Chinese characters, Romaji to Japanese kana and kanji, Hinglish to Devanagari, transliterated Latin to Cyrillic, and Arabizi to Arabic script. Each pair also has a free browser-based converter that requires no login. The keyboard itself ships as desktop clients for macOS, Windows and Linux, plus mobile apps for iOS and Android, with a Homebrew cask offered for macOS. The company points to a separate write-up covering how it evaluates sentence conversion accuracy and English token retention; the dev.to post itself does not include headline benchmark figures.
Why it matters
Mode switching is a small tax multiplied across every sentence a multilingual developer types, and the cost of getting it wrong — a mangled commit message or identifier — is high enough that people build whole habits around avoiding it. Unetype's argument is that this is fundamentally a modelling problem rather than a UX problem: disambiguating phonetic spans from code tokens needs contextual inference that dictionary IMEs lack, while generic chat assistants overreach by translating instead of transliterating. The choice of dedicated 0.8B and 4B models, well below typical chat-scale LLMs, points at the tight latency budget of an input loop, where conversion has to feel instantaneous. The usual caveats for a vendor engineering post apply: the accuracy and token-retention claims are the company's own, and the post defers to a methodology article rather than publishing comparative numbers. Still, for anyone typing daily across Latin and non-Latin scripts, the described approach — context-aware conversion that leaves code alone — targets a genuine, long-standing pain point in how we enter text.
- #input-methods
- #transliteration
- #large-language-models
- #multilingual
- #developer-tools