Why “henkan counts” for Japanese typing tests
If your typing test treats every character as a single keypress, it quietly disadvantages Japanese users. Most Japanese text is entered by typing a reading (romaji or kana), then triggering conversion (henkan), and often picking from a candidate list. That adds extra, invisible work—conversion keystrokes, navigation, and dwell time in the candidate window—beyond raw character entry. A conversion‑aware test makes those steps visible and measurable. (en.wikipedia.org)
It’s also timely. In a March 3, 2026 reader survey by GIGAZINE, MS‑IME was the most‑used desktop IME among respondents (51.41%), followed by Google Japanese Input (35.82%) and ATOK (9.76%). If most people type through an IME, our benchmarks should understand IMEs. (gigazine.net)
Quick primer: how Japanese IMEs handle conversion
- The flow: users type a reading, press Space or the dedicated Convert key to invoke conversion, then confirm (Enter/number) or navigate to other candidates; Muhenkan (NonConvert) and other keys change modes or cancel. On Windows, MS‑IME documents the candidate window behavior and the key templates for both MS‑IME and ATOK styles. (support.microsoft.com)
- Mozc (the open‑source engine behind Google Japanese Input on some platforms) exposes conversion states like “Conversion,” “Prediction,” and candidate list structures with focused indexes and page sizes (default 9 per page). This highlights that candidate selection is a first‑class part of the IME workflow. (github.com)
- ATOK publishes detailed key maps (e.g., space/shift+space for next/previous candidate, F6–F10 post‑conversion transforms), underscoring how many non‑character actions can appear in a typical entry. (atok.com)
- Even the number of default suggestion items differs: MS‑IME shows 5 suggestions by default while Google Japanese Input shows 3 (tunable), which can impact navigation load. (news.mynavi.jp)
Hardware note: Japanese keyboards include dedicated Henkan (Convert) and Muhenkan (Non‑convert) keys flanking the space bar; they’re part of the standard IME flow. (en.wikipedia.org)
What to log in a conversion‑aware test
Build your logger around three ideas: keystrokes, window time, and outcomes.
1) Conversion keystrokes
- Count presses of Convert/Henkan, NonConvert/Muhenkan, Space/Shift+Space during composition, arrow keys/Tab/number keys used to navigate/select candidates, and Enter for commit. On Windows, these include VK_CONVERT (0x1C) and VK_NONCONVERT (0x1D). (learn.microsoft.com)
2) Candidate‑window dwell
- Measure the time from the first conversion trigger (e.g., Space or Convert while composing) until the conversion is confirmed or canceled. Mozc’s candidate UI is explicit in its data model (focused index, page size, window location), and MS‑IME documents when conversion candidates appear versus predictive suggestions—use these semantics to define window‑open vs. closed periods. (code.googlesource.com)
3) Confirmed‑conversion rate (CCR) and Top‑1 acceptance
- For each conversion episode, record whether the first candidate was accepted without navigation (“Top‑1”), or whether the user navigated/pages/typed more before commit. Report CCR (commits per conversion started) and Top‑1 rate; both reflect IME quality on your corpus as actually experienced by typists. (code.googlesource.com)
Bonus: Keystrokes Per Character (KSPC)
- KSPC is a standard HCI metric: total keystrokes divided by produced characters. For English QWERTY, KSPC≈1; conversion workflows push KSPC higher. Logging KSPC makes cross‑language comparisons more honest. (yorku.ca)
How to implement the logging
Web (browser) harness
- Listen to composition events: compositionstart, compositionupdate, compositionend. Between updates, pair beforeinput/input events with inputType="insertCompositionText" to detect IME‑driven text without double‑counting. Use timestamps to bound conversion episodes and candidate‑window dwell heuristically (from first conversion trigger during composition to compositionend). (w3c.github.io)
- While isComposing is true, capture keydown of Space/Shift+Space/Arrow/Tab/Enter/number keys and, where exposed, Convert/NonConvert, to count navigation and confirms. This yields KSPC and CCR from the web alone. (w3c.github.io)
Windows native harness
- If you can go native, use IME/TMF APIs for precise state: WM_IME_STARTCOMPOSITION/WM_IME_COMPOSITION/WM_IME_ENDCOMPOSITION to track composition lifecycles, and Text Services Framework (TSF) UI element hooks (ITfUIElementMgr::BeginUIElement / UpdateUIElement / EndUIElement) to detect when a candidate list opens/closes. That gives definitive candidate‑window dwell, selection counts, and commits. (github.com)
- For low‑level key accounting, log VK_CONVERT/VK_NONCONVERT and friends to categorize conversion keystrokes accurately. (learn.microsoft.com)
Linux/macOS
- With Mozc on Linux (IBus/Fcitx), you can’t always see the IME UI directly from the app, but composition events and keystrokes still surface to your test. Mozc’s docs also describe when Mozc renders its own candidate window versus delegating to IBus—use that to set expectations for dwell heuristics. (github.com)
- On macOS (Kotoeri/ATOK), the same composition events and ATOK’s documented key behavior make it feasible to log conversions even if candidate UI visibility is opaque to your process. (atok.com)
Computing a language‑fair WPM
Continue to publish standard WPM so scores stay comparable: WPM = (confirmed characters ÷ 5) ÷ minutes. But add IME‑aware context:
- KSPC = total keystrokes (including conversion/navigation) ÷ confirmed characters.
- Conversion‑Adjusted WPM (optional): normalize your WPM to a baseline KSPC of 1 to estimate “what this speed would look like without conversion overhead.” One simple approach is WPM_fair = WPM × KSPC. Report both values side‑by‑side, plus CCR, Top‑1 rate, and average candidate‑window dwell. Cite the 5‑chars‑per‑word convention and KSPC’s role when you explain the metric. (en.wikipedia.org)
Example report block per run
- Raw WPM / Accuracy
- KSPC and share of conversion/navigation keystrokes
- Conversions started → committed (CCR%)
- Top‑1 acceptance rate
- Avg candidate‑window dwell (ms)
Practical tips that improve data quality
- Use texts that actually need conversion: include homophones, proper nouns, and mixed‑script phrases so candidate windows open naturally. Mozc’s candidate paging (default 9 per page) and MS‑IME’s Space/Shift+Space semantics make navigation measurable. (code.googlesource.com)
- Separate “prediction” vs “conversion”: in your logs, distinguish Tab‑driven prefix predictions from Space‑driven conversions; they produce different candidate experiences (and counts in popular IMEs). (github.com)
- Attribute commits correctly: treat Enter and number‑selection as explicit confirmation; immediate Enter after first Space without any navigation is a Top‑1 accept.
- Respect privacy: don’t store pre‑conversion readings or committed text; keep only anonymized event types and timings.
- Calibrate by IME: if your test app can detect the active engine (MS‑IME, Mozc/Google, ATOK), store that string with each session for later segmentation. MS‑IME remains widely used, so you’ll want slices by engine. (gigazine.net)
Why this matters (and why now)
Because conversion is the norm, not the exception, in Japanese text entry. IMEs surface rich states—candidate windows, selections, re‑conversion—and mainstream engines document these behaviors. If we capture them, we can finally credit Japanese typists for the work they already do and produce language‑fair leaderboards. (support.microsoft.com)
