「きゅり」と入力して変換すると「きゅうり」になる

[faketanaka]

Description

「きゅり」と入力して変換を試みると、「きゅうり」に変換される。なお、もしかして変換は無効にしている。

Steps to reproduce

Steps to reproduce the behavior:

1. きゅりとタイプ
2. スペースキーを押す
3. 一番上の候補に「きゅうり」と出る

Expected behavior

Actual behavior

A clear and concise description of what you actually got.

Screenshots

If applicable, add screenshots to help explain your problem.

Version or commit-id

Mozc-2.31.5810.102+24.11.oss

Environment

• OS: Arch Linux
• IMF (for Linux) Fcitx5
• Related Applications Firefoxなど

Investigations

• Whether this issue happens on both Ibus and other IMF (e.g. Fcitx, uim).
  • yes, no, N/A
• Whether this issue happens on other IMEs (e.g. Anthy, SKK).
  • yes, no, N/A
• What applications this issue happens on (e.g. Chromium, gedit).
  • list of applications
• What applications this issue does not happen on (e.g. Chromium, gedit).
  • list of applications, or not-found
• (optional) What versions or commit-ids this issue did not happen on
  (e.g. Mozc-2.28.4960.100+24.11.oss).
  • list of versions or commit-ids, or no-investigation.

Additional context

Add any other context about the problem here.

[kons10]

タイプミス補正機能なのはわかるけど、これはちょっとGBoardみたいなスマホ向けじゃないんだから考えてほしい

[faketanaka]

@kons10 そもそもMozcには「もしかして変換」という機能があり、設定でオン/オフを切り替えられます。
もしかして変換を有効にした場合にどこまでタイプミスを補正するのかは議論の余地がありますが、もしかして変換を無効にしていてもこのような挙動をするのは明確にバグです。

[kons10]

片っ端から無駄な機能を無効にしましたが、まだきゅりがきゅうりになってしまいました。私の環境でも

のように、きゅうりになってしまいました。
明確なバグだという意見に賛成です。

Environment

OS: Kubuntu + UKUI + LXQt
IMF (for Linux) Fcitx5
Braveブラウザ、Plasma Discover、Spotify APT版

結論

Archだけではなく、UbuntuのようなDebian系でも発生することが確認された。

[tats-u]

もしかしては全く別ですね

ほにゃ（honya）→ほんや（honnya）みたいな訂正が過剰に行われたものと認識しています。

[tats-u]

ATOKでも同様の挙動が見られるのでwon't fixになるかもしれませんのでご覚悟を

ATOK

MS-IMEでは最上位ではありませんでしたが、2番目以降は全部きゅうりです。

MS-IME

そもそも日本語の語彙で「きゅり」はないはずです、「キュリー」「きゅうり」のどちらかならありますが

[faketanaka]

ATOKでも同様の挙動が見られるのでwon't fixになるかもしれませんのでご覚悟を

よそのみんなに同じバグがあるから修正しなくてもいいという考え方はいただけませんね。こういうことは「もしかして変換」でやるべきですし、そこに含めるのが問題ならもしかして変換とは別に「ミスタイプ修正」みたいな設定を設けてオン・オフをユーザーが選べるようにすべきです。

そもそも日本語の語彙で「きゅり」はないはずです、「キュリー」「きゅうり」のどちらかならありますが

このバグに気づいた経緯を述べますと、「きゅりこ」と入力したら「きゅうりこ」と変換されたことです。なお、「キュリコ」は自動販売機の商標です。
「きゅり」という語彙がないことには同意します。しかし、「きゅり」から始まる語はいくらでもあるでしょう。ウィキペディアにある言葉で調べましたが、「きゅりえいと」がキュリエイトではなく「きゅうりエイト」に変換されますし、「きゅりくす」も同じ問題を抱えています。このバグは修正されるべきです。

[tats-u]

「キュリコ」は自動販売機の商標です。
ウィキペディアにある言葉

ありがとうございます。キュリコ含めて全部カタカナ語でキュリー派生語がほとんどですね。これらの語彙でもう一度確認してみます。

泥版Gboard（内部でMozcエンジン使用）だと「きゅうりこ」が最上位でしたが、「キュリコ」も10位以内には出てきました。1回確定すると「きゅうりこ」を抑えて最上位に躍り出てきました。「キュリー」に至っては「きゅうりー」はありませんでした。
Google日本語入力開発版の場合、「キュリコ」に関しては最初は「きゅうり」+「こ」の2文節になりますが、Shift + →で1文節化すると、「きゅうり」は消えます。次回からはこの1文節で変換されるのできゅうり混入はなくなります。
あくまでも今すぐには素のMozcを試せないがゆえの妥協暫定報告でしかないので参考にしかなりませんが・・・

あとはAnthyやKKCでの挙動も確認したいですがLinuxデスクトップ環境は今はないので試せません

[tats-u]

よそのみんなに同じバグがあるから修正しなくてもいいという考え方はいただけませんね。

唯一金を取っているATOKの挙動は一定の権威を持っています。（個人的に言葉狩りが不快ですが）そこも同じならば単なるバグではなくむしろ仕様に近いものではないかということです。MS-IMEもきゅうりと疑っていますしそこは既定路線と考えられるでしょう。

こういうことは「もしかして変換」でやるべきですし

あれは候補がごく少数の場合に使えるものであって、「きゅうり」の候補は果物以外にもあるのでそれこそサジェスト欄が汚染されてしまうことを懸念します。また、「きゅしゅう」→「きゅうしゅう」の訂正だと「九州」がつく語の多さからもっと候補は爆発します。もしかしてエントリテキストファイルの行数がすごいことになります。

[yukawa]

Hi all,

I am converting this issue to a Discussion.

The conversation here has shifted towards feature requests and behavioral preferences rather than tracking a simple conversion issue. Since there is no clear, risk-free path to "close" this issue in the near future, I believe it is more constructive to host this conversation in Discussions for now.

For technical context, the behavior discussed here is controlled by RewriteYu in key_corrector.cc, which has been there for more than 15 years.

mozc/src/converter/key_corrector.cc

Lines 310 to 361 in d91f278

	// Not implemented yet, as they looks minor
	// "[子音][ゃゅょ][^う]" Pattern
	// "きゅ[^う] -> きゅう"
	// "しゅ[^う] -> しゅう"
	// "ちゅ[^う] -> ちゅう"
	// "にゅ[^う] -> にゅう"
	// "ひゅ[^う] -> ひゅう"
	// "りゅ[^う] -> りゅう"
	bool RewriteYu(size_t key_pos, absl::string_view prefix, size_t* mblen,
	std::string* output) {
	const char32_t first_char = Util::Utf8ToCodepoint(prefix, mblen);
	if (first_char != 0x304D && first_char != 0x3057 && first_char != 0x3061 &&
	first_char != 0x306B && first_char != 0x3072 &&
	first_char != 0x308A) { // !"きしちにひり"
	*mblen = 0;
	return false;
	}
	prefix.remove_prefix(*mblen);
	if (prefix.empty()) {
	*mblen = 0;
	return false;
	}
	size_t mblen2 = 0;
	const char32_t next_char = Util::Utf8ToCodepoint(prefix, &mblen2);
	if (next_char != 0x3085) { // "ゅ"
	*mblen = 0;
	return false;
	}
	prefix.remove_prefix(mblen2);
	if (prefix.empty()) {
	*mblen = 0;
	return false;
	}
	size_t mblen3 = 0;
	const char32_t last_char = Util::Utf8ToCodepoint(prefix, &mblen3);
	if (last_char == 0x3046) { // "う"
	*mblen = 0;
	return false;
	}
	// OK, rewrite
	*mblen += mblen2;
	Util::CodepointToUtf8Append(first_char, output);
	Util::CodepointToUtf8Append(next_char, output); // "ゅ"
	Util::CodepointToUtf8Append(0x3046, output); // "う"
	return true;
	}

If you would like completely disable KeyCorrector including RewriteYu, I guess you can simply let KeyCorrector::Init() always return false.

mozc/src/converter/key_corrector.cc

Lines 378 to 390 in d91f278

	bool KeyCorrector::Init(absl::string_view key, InputMode mode,
	size_t history_size) {
	// TODO(taku) support KANA
	if (mode == KANA) {
	return false;
	}
	if (key.empty() || key.size() >= kMaxSize) {
	MOZC_VLOG(1) << "invalid key length";
	return false;
	}
	original_key_ = key;

--- a/src/converter/key_corrector.cc
+++ b/src/converter/key_corrector.cc
 bool KeyCorrector::Init(absl::string_view key, InputMode mode,
                         size_t history_size) {
+  return false;
+
   // TODO(taku)  support KANA
   if (mode == KANA) {
     return false;