In an IME that detects Japanese, Chinese and English on its own, converting in small pieces costs you

I write in a mix of Japanese, English and Chinese every day, and the thing that wears on me most is switching input methods. I forget to hit Ctrl+Space, type nihao and get にはお, delete it, switch, and type it again. Dozens of times a day.

So why not let the IME guess the language from the keys I type? I added automatic English and Chinese detection to fcitx5 + hazkey (the AzooKey engine with Zenzai, a neural kana-kanji converter). There is no switch key. kyouhaiitenkidesune (今日はいい天気ですね), meeting and nihao are all typed in the same state.

After using it for a while I noticed something odd: typing a longer stretch before converting clearly meant fewer corrections. That is the opposite of how people usually use an IME, so I measured it.

A normal IME rewards converting in small pieces

People who have used a Japanese IME for years tend to convert and commit one phrase (bunsetsu) at a time, or a few at a time. Converting a whole sentence at once has existed for decades, but when a long conversion goes wrong, fixing the phrase boundaries and re-picking candidates is a chore. Committing often keeps the damage small when something goes wrong. It's a sensible habit.

In an IME that detects the language by itself, that premise falls apart, for two reasons.

1. Language detection fails more on short input. nihao (你好), wo (我) and ma (吗) are all perfectly readable as Japanese romaji. I built a classifier that guesses the language from the key sequence alone and measured it by length: 89% correct at 3 characters, 99% at 8 or more. A short input simply doesn't carry enough to decide.
2. The converter looks at the whole input. Zenzai is a neural kana-kanji converter that uses the entire input as context. Whether かれは becomes 彼は ("he") or 枯葉 ("dead leaves") can't be decided without seeing what comes after it.

What I built

• English detection: a log-likelihood ratio over character 1–5-grams (English vs Japanese romaji). If the input looks like English, the letters as typed become the top candidate. If an English word sits inside a longer input, a DP splits it into English and Japanese spans. For example, kinouhagithubnosetteiwokaeta → 昨日はgithubの設定を変えた ("I changed the github settings yesterday").
• Chinese detection: after the English check, an n-gram model of the same shape decides pinyin vs Japanese romaji. If it looks like Chinese, it is converted by libime, the same engine as fcitx5's own pinyin input, running as a separate process (2.8 ms per phrase).
• Context: if the text just before the cursor contains kana, lean Japanese; otherwise lean toward whatever language was committed last. The second rule is needed because some apps, Discord for example, don't pass the surrounding text to the IME.

Japanese romaji and pinyin overlap heavily: 46% of Japanese chunks can also be split into valid pinyin syllables. So "can this be read as pinyin?" barely helps. What helps is length and context.

How I measured it

I took sentences from Tatoeba and typed the same key sequence, changing only where it was cut:

• Convert and commit each phrase, with no context (like an app that doesn't pass surrounding text)
• Convert and commit each phrase, passing the committed text as context for the next conversion
• Two phrases at a time / four phrases at a time
• The whole sentence at once

Each piece is committed with the top candidate, and I compare the result to the reference: character error rate (CER) and the share of sentences that come out exactly right. I also measured a second way of typing, "fixing as you go": for each piece, if the top candidate is wrong and the right one is in the list, pick it. The number of times the top candidate was wrong is the "fixes" count. To keep learning from leaking into the results, the server is restarted for every sentence.

Three data sets, 150 sentences each:

• Japanese only
• Japanese with an English word mixed in (a noun followed by a particle replaced with github, meeting and so on)
• Chinese (word boundaries from jieba)

Results

Japanese only (5.2 phrases on average)

Converted at once	Error rate	Sentence exact	Fixes/sentence
Per phrase, no context	11.9%	31%	1.21
Per phrase, with context	6.8%	57%	0.60
Two phrases	4.1%	64%	0.42
Four phrases	3.8%	66%	0.37
Whole sentence	3.6%	68%	0.32

Even with Japanese alone, where language detection barely matters, longer is better. The improvement comes in two steps.

• From no context to context, the fixes halve. That is the effect of the left context.
• From per-phrase to whole sentence, they halve again. That is the effect of the right context: what comes after.

You can pass the left context to the IME, but the right context exists only in the typist's head. The typical miss is かれは → 枯葉: committing phrase by phrase means deciding before seeing シャーウッドの森を ("Sherwood Forest") that follows.

Japanese with English (5.5 phrases on average)

Converted at once	Error rate	Sentence exact	Fixes/sentence
Per phrase, no context	11.5%	31%	1.17
Per phrase, with context	7.3%	50%	0.68
Two phrases	6.3%	55%	0.50
Four phrases	5.9%	56%	0.45
Whole sentence	5.9%	59%	0.41

Same trend. It levels off at around four phrases.

Chinese (7.2 words on average)

Converted at once	Error rate	Sentence exact	Fixes/sentence
Per word, no context	66%	12%	1.85
Per word, with context	85%	12%	1.84
Two words	34%	42%	0.86
Four words	23%	55%	0.62
Whole sentence	14%	57%	0.43

This is where it shows most clearly. Typed one word at a time, the input isn't treated as Chinese at all.

你快要走了。          → に快要走了。
你和我有一些共同点。   → にheをyouyixiegongtongdian。

ni and he are two letters long, and reading them as Japanese romaji is the more natural guess. Passing context even makes it worse (66% → 85%). Once the first ni becomes に, that becomes "the previous text was Japanese", which pulls the next pinyin toward Japanese too. Each wrong result feeds the next decision, and the errors chain.

Type the whole sentence and seven words of pinyin are hard to mistake for anything but Chinese.

The way you type flips

In a normal IME, cutting often was insurance: it kept the damage small when a conversion went wrong. In an IME that detects the language, cutting is what causes the errors.

• Japanese alone: the whole sentence needs about half the fixes of per-phrase (0.60 → 0.32)
• Chinese: a quarter (1.84 → 0.43)
• The worst case is per-phrase in an app that passes no context (1.21 for Japanese, 1.85 for Chinese)

A long input is no longer "a pain when it goes wrong". It's the material that makes it go right. In actual use, too, I drifted toward typing all the way to the punctuation and then pressing Space.

Bugs the measurement found

As it turned out, this measurement was more useful as an audit of the implementation than as material for an article.

• Every Chinese sentence with a comma in the middle came out garbled. libime can't read input containing punctuation, so nihao,wojiaoqingshui. came out as Japanese kana. 15% of the Chinese sentences have a comma in the middle. After splitting at punctuation and converting each piece separately, the whole-sentence error rate dropped from 39% to 14%. The Chinese table above is after the fix.
• In longer input, youtube becomes ようつべ (Japanese slang for YouTube). Per phrase it stays English, but once two or more phrases are converted together, Zenzai's conversion wins. Not fixed yet.

While I was testing by typing one sentence at a time, I noticed neither. The comma bug hits the "longer is better" claim head-on. Had I written this without measuring, I would have misread the Chinese result as "longer doesn't help much".

Limits of these numbers

• The error rate includes spelling variants (ご飯 vs ごはん, 行った vs いった). They are counted the same way for every cut, so the comparison holds.
• The "fixes" count assumes an ideal typist who always picks the right candidate when it's in the list.
• Tatoeba sentences are short (about five phrases). I haven't measured whether longer paragraphs level off or get worse.
• Chinese is cut at jieba's word boundaries, which may differ from where people actually pause.
• Only top-candidate correctness was measured, not conversion time. Zenzai takes around 200 ms per sentence on CPU, so converting a whole sentence is heavier than the live suggestions shown while typing.

Closing

I had a vague feeling that longer was better from using it. Measured, the difference was clear even for Japanese alone, and for Chinese it was large enough that the IME is unusable unless you change how you type. How an IME feels depends on the engine together with the typist's habit of where to cut, and when the engine changes, the best habit changes too.