DEV Community

losdwind
losdwind

Posted on

Why We Trained 0.8B and 4B Transliteration Models for Mixed-Script Input Methods (No Mode-Switching)

#ai #llm #machinelearning #softwaredevelopment

If you write software documentation, Slack messages, or bilingual notes across two scripts—say Simplified Chinese + English, Japanese + English, Hindi + English, or Arabic + English—you already know the mode-switching tax of traditional input method editors (IMEs).

Every time an English identifier (README, useEffect, roadmap, v1.0.22) appears in the middle of a Pinyin or Romaji sentence, a conventional character-by-character IME forces you to toggle layouts (Ctrl+Space or the Globe key), pick candidates, toggle back for the English token, and toggle again.

On the other hand, general-purpose LLM translators fail in the opposite direction: if you feed them a mixed draft like jintian yao finish README or kyou wa Tokyo de meeting ga arimasu, they translate the entire sentence into a single language instead of preserving intentional bilingual code-switching.

That gap is why we built UnimeType—a cross-platform input method and set of browser converters—and open-sourced our specialized Transliteration 2.0 (0.8B & 4B) models under Apache-2.0.

1. The Core Problem: Transliteration != Translation

In a mixed-script input workflow, the user types phonetic Latin text on a single QWERTY layout:

  • Chinese (Pinyin + English): women xiazhou release v2.1, qing xian check PR → 我们下周 release v2.1，请先 check PR
  • Japanese (Romaji + English): kyou wa Tokyo de team meeting ga arimasu → 今日は Tokyo で team meeting があります
  • Hindi (Hinglish + English): kal morning mein deployment check karna hai → कल morning में deployment check करना है
  • Arabic (Arabizi + English): ana fil meeting dilwa2ti, hab3at el PR ba3dein → أنا في ال meeting دلوقتي، هبعت ال PR بعدين
  • Russian (Translit + English): davai zavtra obsudim release plan → давай завтра обсудим release plan

A model serving an input method has three hard constraints that general chat LLMs violate out of the box:

  1. Boundary preservation: Recognized English words, code identifiers, flags, URLs, and @handles must stay in Latin script unless they are phonetic syllables of the target script.
  2. Ambiguous homophone disambiguation in context: Token-level syllables like you (English pronoun you vs. Chinese Pinyin 有/又), main (English main vs. Hindi मैं), or de / to (English prepositions vs. Chinese/Japanese particles) can only be resolved by looking at the surrounding clause.
  3. Sub-second latency & zero conversational chatter: An IME cannot wait 3 seconds for a chain-of-thought reasoning block or strip conversational filler like "Here is your converted text:".

2. Training UnimeType/Transliteration-2.0-0.8B and 4B

To make full-sentence mixed-script conversion fast enough for local desktop inference (via LM Studio / llama.cpp / MLX) and low-latency cloud routing, we fine-tuned two model sizes on Qwen/Qwen3.5:

Both models use a compact Short-Protocol (v2.1) system prompt with thinking disabled (enable_thinking=False) so the first output token is emitted immediately.

We published our full benchmark methodology—covering 900+ multi-script test cases, homophone collision traps, and English-retention stress tests—in How We Evaluate Transliteration Models.

3. Try It in the Browser (Zero Install) or Locally

We recently shipped four free, no-sign-in browser converters powered by the same conversion pipeline so you can test full-sentence mixed-script conversion directly in the browser:

If you want system-wide conversion inside any native app (VS Code, Slack, Notion, WeChat, browsers, terminals), along with in-place AI Polish Writing and AI Text Explainer:

Feedback on tricky bilingual boundary cases or host-editor quirks is very welcome!

Top comments (0)