日本語入力メソッド総合スレッド [無断転載禁止]©2ch.net

>>346
コンポジタはGnomeのMutter
アプリは↓のフラグを付けてのXwaylandを介さないWaylandネイティブでの起動
"--ozone-platform-hint=auto --wayland-text-input-version=3 --enable-wayland-ime --gtk-version=4"

Electron 36ベース(Chromium 137ベース)のSiki 0.36.3までは頻繁に単語が二重に入力されたり、アプリとIMEの接続が切れたりと不安定だった
メインのWebブラウザはFirefoxでChromiumはめったに使わないから詳しくは動作状況を記憶していないが、こちらも同様の症状が見られた
今、書き込みに使ってるのはIbus-Anthyを載せてるサブPCだが、GnomeにFcitx5-Mozcを載せてるメインPCでも同じ状態でIMEに起因する動作差異は無いと思われる

なるほど
wlrootsを使ったコンポジタだと前から入力に関してはその方法で入力できてたんだ
だからmutterの問題が改善したのかもしれん
現にwestonだと未だに全く入力できない

>>348
改めて調べ直したらChromiumはもともとWayland text input protcol v1を実装してて
v1をサポートしてるコンポジタでは普通に日本語入力できてたっぽい
Mutterは後方互換を無視してv3のみのサポートだったのが不安定だった原因みたい😅

起動フラグも見直したら"-ozone-platform-hint=auto"だけで日本語入力できるようになってた

👏
mutterの野郎のせいだったのか

Chromiumがぎりぎりまでv3の実装を渋ってただけだろ
セキュリティの弱点になりかねないから

OSCで日本語入力を開発してる奴がいなかった？
永遠にリリースしないやつ

おまえら支那語入力システムが好きなんだね

支那語入力システムは知らんけど、
支那製日本語入力システムを好きで使っている。
https://github.com/fcitx/fcitx5-skk

だってよう
漢字日常使ってんの日本語と中国語だけなんだぜ
で、中国語話者のほうが圧倒的に多いんだから「支那語入力システム」に頼るのも仕方ないだろう

uimがgtk-4に対応してくれればなぁ

hazukeyがめっちゃ使いやすいんだけど、半角変換とか、カタカナ変換とかショートカットないよね。
みんなどうしてる？ ファンクション？

>>357
半角変換とか、カタカナ変換とかのショートカットが何を指すか知らないが、
そんな必要機能が見つからないのにめっちゃ使いやすいって、どういうこと。

自分の環境だと普通にF7でカタカナ、F10で半角に変換してうけど

自分の環境だと普通にF7でカタカナ、F9で全角に変換してうけど

mozcではF8で半角カナ変換一発だなあ
全角仮名は無変換2回押しでok
hazkeyでは違う？？

ファンクションキーによる変換は出来るけどキーボードショートカットのCtrl+T,U,I,Oによる変換は出来ないという話か

hazkeyでも一緒

自分的にはCtrl押すならファンクション押す派だから問題ないけど
文節の変更の時の方が手間どるわ

hazkeyのキーバインドはここに
MACはよく知らないんだけど、多分、Macの”ことえり”と同じキーバインドかな？
https://github.com/7ka-Hiira/fcitx5-hazkey/blob/main/docs/basic.md

自分は日本語キーボードなんですが、下記のようにしています。
Fcitx5　グローバルオプション
1.入力メソッドの切り替え　ctrl+spaceを無効にしてひらがなカタカナキーに割り当ててる。
※nvimとかのキーバインドとバッテングする可能性があるため。
2.一時的に第1入力メソッドに切り替えるを左シフトとバッテングするので、Ctrl+左Shift

文脈変換がすごくてかなり助かってます。
Zenzai contextual conversion
https://github.com/7ka-Hiira/fcitx5-hazkey/blob/main/docs/zenzai.md

mozc-utが元々の辞書登録がすごく優秀でよかったんだけど、なくなってしまったので探してたらHazukeyに出会いました。
mozcは登録した辞書が優先的に変換候補の上位にあがってくる仕様だし。
User辞書に変な癖がついてしまってたまに変換爆発してなんなのみたいな文章を吐き出すし。
hazukeyは本当に快適ですよ>>358

でもhazkeyは辞書登録できないのがなあ……

辞書登録とかそういう問題でないような気がするんだよね。
mozcとかSKKって辞書ベースと形態素解析だったんだよね。
それがニューラルネットワークによる文脈変換ってに変わっていくと思うんだよね。
Hazkeyの設定画面にあるだけで有効にならないLearn modeに期待かな。
一度変換して覚えさせたら文脈見てそれに変換するとか。

>>367
辞書登録できなきゃ即時的に新語、専門用語や造語に対応できないだろバカ

Mozcだけじゃないけども、その辞書登録がイマイチ。
ATOKや昔のMS-IMEだと、ユーザー辞書の優先度は学習や文脈と組み合わせて調整されていたけど、Mozcはそこが単純すぎる。
辞書登録されたものが優先的に変換候補に上がるし、形態素解析（MeCab辞書）を壊してしまう可能性というかあるんだけど。
学習に任せば任せたで、不自然な分割が正しいと認識したり、間違った係り受けが固定化されたり。
google日本語入力はその辺をきちんとするために、クラウド同期や豊富な語彙があるんだけど、Mozc-utがなくなってそこも、
もうMozcには期待できないし。
今の現状で不憫なく使えてるなら、そのままでいいんじゃねぇの？　

全文書いてくれるようになるから
"お" って入力すると「お前を殺す」って出るようになるよ

デデン！

でもふべんをふびんって読むやつは、まともな入力できなさそう。

>>372
自ら変換精度下げに行ってる感あるよな

>>370
ワイ、IMEの誤変換をGitHub Copilotのサジェスションで再変換してるが、今月分のクォータを
先週金曜日に使い果たしたので完全におバカ変換のまま誰も修正してくれない状態になってる。
　あと2日間はプログラミングも文書も作りたくない。

おまえのアタマで変換しないからそういうことになるw

AzooKeyを利用したSKKサーバだと

GitHub - gitusp/azoo-key-skkserv
https://github.com/gitusp/azoo-key-skkserv

skkserv を使える SKK は今もあるのだろうか。

何言ってんだコイツ

Java製アプリでibus-mozcなんだが変な挙動が発生するよ
あさと入力して変換すると朝になるけどもう一度変換キーを押すとこうなる
https://i.imgur.com/nsAV34F.jpeg
そして何度か変換キーを押していくとこうなる
https://i.imgur.com/qleFhsP.jpeg
ここでenterキーを押すとこうなる
https://i.imgur.com/8C8LEcW.jpeg
で、全部消してあさと入力すると亡霊のように復活する
https://i.imgur.com/D2zg0uD.jpeg
一度入力欄を消して再度出さないと正常に戻らない

絵文字が候補に出てこないように設定すればどうなる？

>>380
上記の不具合は絵文字のところを通るとなるので絵文字変換のチェックを外せば当然問題は起きないですね

リアルタイム変換オフにしたらなにか変わるかもしれんとChatGptが言ってました。
他にも色々ChatGpt言ってたけれど、貼る？

>>382
よろ

リアルタイム変換オフは意味なかった

>>384
あら

なるほど、その挙動は「未確定（preedit）文字列が Java 側で正しく終端されず、Mozc が古い構文状態を保持したまま“亡霊”のように復活する」タイプの不整合っぽいです。Linux の Java（AWT/Swing/SWT）× ibus-mozc で時々出るやつ。まずは“確実に効くことが多い順”に対策を並べます。質問なしで一気に試せるよう、コマンド／起動オプションも付けました。

恒久対策（Java×IBusの相性対処）
A. XIMブリッジ経由に切り替える（安定しやすい）

Java は XWayland/X11 だと XIM 経由が安定することが多いです。

パッケージ確認（Ubuntu/KDE Neon 想定）
sudo apt install ibus ibus-mozc ibus-gtk ibus-gtk3 ibus-xim

環境変数を設定して ibus を XIM 有効で起動
ibus-daemon --xim -drx
export XMODIFIERS=@im=ibus
export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus

問題の Java アプリをこの環境で起動（例：jar の場合）
XMODIFIERS=@im=ibus GTK_IM_MODULE=ibus QT_IM_MODULE=ibus \
ibus-daemon --xim -drx
java -jar yourapp.jar

ひらがなIMEってのを見つけたんだけど、使ってる人います？

Java の入力方式ヒントを変える（preedit描画モードの切替）

Java は IME の描画モードをプロパティで変えられます。アプリ起動時にどちらかを試してください（両方試すのがコツ）。

on-the-spot（その場描画）を明示：
java -Djava.awt.im.style=on-the-spot -jar yourapp.jar

over-the-spot（候補を上書き表示）を明示：
java -Djava.awt.im.style=over-the-spot -jar yourapp.jar

※ 片方でゴーストが消えることがよくあります。

Wayland → X11 での再現確認（KDE Neon）

Wayland セッションだと Java(AWT/Swing) の IME が不安定になることがあります。X11 セッションでログインし直して再現が消えるか確認してください。
→ 消えるなら、普段は X11 で使う or A 案（XIM）を徹底するのが無難です

アプリが SWT（Eclipse系）の場合

SWT は GTK 経由で IME が入ります。A案の環境変数に加え、GTK を明示するのが効くことがあります。

export SWT_GTK3=1 # まずは 1 で。ダメなら 0 も試す
XMODIFIERS=@im=ibus GTK_IM_MODULE=ibus QT_IM_MODULE=ibus \
ibus-daemon --xim -drx
your-swt-app

>>387
すみません、Chagptの回答抜粋はってました。
>>386 >>388-390が回答抜粋です

>>391
大量にありがとうございます

hazkey0.2.0がリリースされたよー

hazkey 0.2.0、JISかな入力で不具合

漢シ゛カ゛上手く入力て゛きません。
ハ゜ヒ゜フ゜へ゜ホ゜
カ゛キ゛ク゛ケ゛コ゛

hazkey早速インストールしてみた

コレかな入力の際にはよく多用していたcapsキーによる
半角英数文字入力切り替えできないのね

無念

自分はHazkeyのRPM版がほしいです。
今回のビルドの情報はありがたいのですが、Swiftがいるのででハードル高くて。

>>394 です
hazkey 0.2.0 を一度アンインストールし、~/.config/hazkeyを削除
reboot、再インストールしたらJISかなで正常に入力できました

Debian 13でibus-anthyで親指シフトを使っているが、親指シフトキーボードを選択しても実際には変更が反映されなくて困ってる。

そもそも、親指シフトのメンテナーが海外にいると思う？
テストすらできないんじゃないの？

PS/2コネクタがついてるパソコンを使ってるってことかなぁ？
なんかすごい。

ibus-anthyはpythonのプログラムで、キーボードの種類を選択させてキーマップを変えているだけで、ハードウェアを直接制御しているわけではないと思う。
単にソフトウェア上のバグでキーマップを読み込めていないだけだと思う
あと状態管理がおかしいのかキーマップをカスタマイズしようとしても保存されない
使っている親指シフトキーボードはUSBキーボード

親指ならoyainputなるものがあるそうですね
fcitx5-mozc + oyainput + oyainput.patch などで動作するみたいですよ

>>400
USB接続のもあったよ
PS/2コネクタのキーボードをUSBポートに繋げる変換コードもあるし

>>403
わかるけども、それじゃない。
めっちゃ相性問題でそうじゃない。＞USB変換
他のOS？（あるのか）でもちゃんと使えてるよねテストをしないと。

hazkeyはかな入力だと「ロ→ー」になってしまうな 困っちゃうな

>>404
low levelのkey eventはlibinputツールで確認出来る

>>406
その前にlsusbでしょう？USB変換ならね。
USBからみたら普通のキーボードって認識してるじゃないの？
PS/2コネクターはLinuxでどうすればいいか知らない。

昔マウスに付属してたような配線だけ変換するようなアダプトだと無理だけど
信号もきちんと変換するアダプタなら行けるだろうよ
やったことはないけど

>>407
逆です
libinputでeventが発生してるか調べる
発生してなければdeviceの健全性を調べる
発生していれば自分の意図通りのeventか調べる

>>409
どうでもいいけど、それは違うな。
解決しない、まずはこれ。
まぁ好きにすれば〜。どうでもいい。PS/2 USB変換とかしないし。

１lsusb (ハードウェア認識) ← ここから始める
dmesg / journalctl (カーネル/ドライバのロード)
libinput / xinput (入力デバイス制御)

ibus-anthyで親指シフトの設定がどのように保存されているか調べるためにdconf-editorを入れて調べた。
そうこうしているうちにカスタマイズしたキーマップが保存できるようになっていた。
キーボードの設定は反映されていないままだけど、打てなかった「、」などが打てるようになって、使えるようにはなった。
ibusに登録できていないのが原因ではないかと思っているけどソースコードを書き換えるのはしんどいので追求するのはやめた。

スレが上がってるから、mozc-ut2の話かと思ったのに...

>>412
何だそれは？

>>410
USB変換してるかどうかはっきりしてない
だから包括的に扱ってるlibinputから始める

親指シフトのキーマップのbaseは読み込めて反映されていたので親指シフトの基本的な部分は最初から動いていた。
拡張のキーマップが反映されなかっただけなので、baseを書き換えて保存できれば拡張部分も再現できて問題はなくなった。
scim-anthyもnicola-f, kb-611などの設定が有効になっていないので同じ問題があったが、scim-anthyは書き換えたキーマップを保存できた。
Debian 13になってscim-anthyを動かすと1時間くらいでDesktop環境ごと落ちてしまう問題に見舞われたので、ibus-anthyに変えた。

>>402
oyainput.patchは知らなかったけどoyainputは使ったことがある
かなと英数との切り替えがスムーズにいかなかったので使うのをやめた

時間があればoyainput.patchを試します
ありがとうございました

usbじゃないハードは、lshwで調べる。
たぶん、ps/2はisa-pciの下につながってる。

>>417
へーありがとう！
USBでもisa-pciでも結局はHID（Human Interface Device）になるんだよね。
で、キー配列は所詮ソフト的なレイヤーだから、ぶっちゃけ普通の英語キーボードに親指シフトのキーバインド割り当てても問題なし。
まぁ使えないけども。
ちなみに最近知ったのは、自分たちの使ってる日本語キーボードって正しくは、"L-shaped Enter "ってつくらしい。
スレちな話だけど奥が深いよね＞キーボード。

ドイツ語キーボードもLshape

JISはbackward-Lじゃなくて180°turn-L多い

>>418
設定してから iBusを再起動してる？
再起動しないと有効にならないよ

ATOKは大手の国語辞典会社との取引をやめてからはひどくて使いものにならなかったな。

辞書を自前の財産としてしか見てないからそうなる
ユーザーのための便利な辞書という概念がない

国語辞典の語彙を網羅すれば便利になるとでも思ってるのか

それを無視するのもね

Google社がゼンリンとの提携をやめたら、ひどいGoogleマップが完成したのと同じ。

🍎の話じゃないのか？
https://www.nikkei.com/article/DGXZZO47270450V11C12A0000000/

fcitx

言語学的なスキルが高い企業がない

他所の話だが、お前を消す方法 再び

マイクロソフトの新しい日本語入力ソフト「Copilot Keyboard」はキュートで賢い
https://forest.watch.impress.co.jp/docs/review/2073660.html

MSをSSDから消せ

>>430
これ賢いんだけどhazkeyと同じく辞書登録ができないんだよなあ
ニューラルネット系はみんなそうなるのかなあ

rpm系なので、Hazkeyないのがめっちゃ不便
swiftは警告出るけどはいるんだよ
そのあとゴニョゴニョしてもインストールできないんだよ（悲）

hazkeyはmozcより良い感じです？

>>432
azookeyやスミレが辞書登録できるからhazkeyがまだってだけでしょ

>>433
ここの話題ではないけど Fedora に debパッケージ入れるの大変なのか。そっち方向で興味湧いた

>>436
deb等のパッケージを使うにはパッケージに含まれないファイルも必要なことがあるけど
それらのファイルの場所はディストリによって違っていることがある
Ubuntuのパッケージは目的のファイルがUbuntuで決められた場所にあることを前提に動作するけど
Fedoraではその場所にないからファイルを見つけられない、ということが起こる
他のディストリの場合も同様

Distrobox / Toolboxって今調べてるんだけど、これならHazykey使えそう？
どうなんだろう？

Hazykey……？fcitx5-mozcで良いのでは

>>438
Toolbox で Debian のコンテナイメージを利用
というサイトでtoolbxの使い方はあるけど、パフォーマンス出るかな、とかはある

>>430
これ今日の更新で辞書登録できるようになってた
まだインポートとエクスポートはできないけど
Windowsの話題でスマソ

mozc 3.33.6079.102

ついにバージョン3か
どんだけ変わるんだろ

Linux用のATOKって、もう完全撤退しちゃったの？？？

>>444
とっくに……

株式会社アイ・エス・ビー
https://kizuna.5ch.net/test/read.cgi/infosys/1756826944/
https://www.isb.co.jp/about/company-profile/

あっ、そっか
ArchはMozc-utが活発にメンテナンスされてるんだ
いいなぁ〜 UTなくなってからきついなぁ
NEologdいれて自分でなんとかするしかないかなぁ
いっそのこと、変換エンジンと辞書は別物にしたほうがみんな幸せになれるんじゃ？

Mozc-2.32.5981.102+24.11.oss

442はarchではないよ
xubuntu daily だよ
ujimushiさんの20250404参考

xubuntu dailyなんですか！！
知りませんでした
変換効率とかどうなんだろう？

mozc はいつになったら句読点確定機能をつけてくれるのか

確定してから句読点をいれてください

支那語に句読点なんてないから

ニホンゴだって文語にはそんなものないんだよ

>>452
> 支那語に句読点なんてないから

現代中文には句読点打たれている場合が多いよ。
維基文庫などに所収の漢籍も、句読点を補われたものが多いよ。

現代はニホンゴの影響があるからだよ

支那語に句読点なんてないから

>>454
現代でいいのでないか。
>>452 は句読点確定機能の話題だと思っていたが、何の話?

そもそもなかった支那語において句読点を基準にした変換を取り入れることはないだろという話

Linuxで今もきちんとメンテされて使える日本語変換は

1. mozc
2. mozc-ut
3. anthy
4.skk
5 .hazkey
skkはよくわからないし、mozcがイマイチな場合は、anthyかな

絶賛開発中のhazkeyと活発に更新されるut辞書を除けば、ほとんど開発が止まって最低限のメンテしかしてないような状態だろ
anthyに至っては後継のanthy-unicodeが出たのに、mozc人気もあっていまいち置き換えが進んでない感じだし

libkkc もメンテされてるよ。
skk 辞書が好きな人向けかな。
カスタマイズ出来る所はmozcより少ないけど、主張も少ないのでワシは好き。
anthy は変換出来ない時は単語の区切りを直さないで変換し続ける動きをするね。
人が工夫して区切れば良いけど。

やっぱり辞書と変換エンジンは分けるべきだよね。
それがたぶん幸せ。

fcitx5-skk は新しいし、ちょこちょこメンテされている。
https://github.com/fcitx/fcitx5-skk/commits/master/

>>456
そもそも句読点がなかったという点では昔の日本語も同じだし、漢字もそもそも支那からの輸入品なのでカナ漢字変換機能を取り入れないかというと、そうじゃないだろう。

日本語入力として出発した
日本語入力の後発の支那語入力として出発した
思想はまるで違うよ。

fcitx5-skk は Enter で確定しても改行しない設定で使っている

>>463
出発点なんて単漢字変換なのに、句読点を基準にした変換なんてある訳ないだろ。

支那語入力システムの方が後発なんだよ
日本語入力システムは既にあった

というかmozcの話だろ
元々は小松弘幸氏と工藤拓氏の二人で始めた本業務外のプロジェクトだ
日本語入力システムとして始まってるのに支那語に句読点なんてないからとか意味分かんねえぞ

支那語をNGにしてスッキリ

fcitx5-mozcで満足してしまった

>>459
これはいい感じですね。ありがとうございます。
SKKはなんだか設定が難しいんだけど、入れたら使える感じですね。

ちょっと確認させてください。うち環かもしれないので。

mozcバージョン：Mozc-2.32.5981.102+24.11.oss
辞書の設定はこんな感じです。
https://i.imgur.com/bE5ObHA.png

ただ、「インターネット」は「innta-netto」だし、「ウィンドウズ」は「Uxinndouzu」だし、「マイクロソフト」は「maikurosofuto」だし。
こんなもん？ mozc-utとかhazkeyは問題ないんだろうなぁ。

libkkc の話で mozc の画面を出すのはワケワカメ

いや、そうか？
hazkeyやmozc-utのない状況でベストな方法を検討中。
SKKは分からないし。多分、修業がいりそう。
いまごそごそやってるのは、libkkcにSKK-JISYO.edictt追加で変換効率上がらないかなぁとか。
mozcにgoogle-ime-user-dictionary-ja-enを追加かなとか。

双極性障害で躁状態だろうから、元気の無い時に見るといいよ

いろいろ試して、やったのは githubからMozc用のカタカナ語英字辞典を持ってきて、word形式やらbom付きとか色々あるので、キレイに精査整形しマージ。
それを元に、Mozc用とlibkkcというかSKK辞書にawkで変換してkkcに反映してmozc、kkc両方とも使えるようにしました。
Microsoft、oracle、Windows (Microsoft operating system)、the Internet まぁ、ちょっと変なのもあるけど使えます。
mozcは辞書登録すると変換が馬鹿になったりするのでしたくなかったんだよね、今後はlibkkcをメインにたまにmozcみたいな使い方で行きたいと思ってます、。
libkkcを教えてくれた人ありがとう!

自分はRockyLinux使いで、日本語入力はmozcをつこてる。セットアップは慣れてるので自分にとっては難しくはない。
でも、超初心にとっては、インストーラーで日本語を選択した段階で自動で日本語入力システムもセットアップされてるとよいと思う。そんなディストリってあるのか？

こんな人もいるから頑張って下さい
https://github.com/jg1uaa/nwc2010-libkkc
昔は他にもあった気がするけど探せなくなっている気がする

>>470
この辺のファイルかも
https://github.com/ueno/libkkc/commit/ce17a35d3dca32706ae2dd48c7859a36531a9b59

「/internet」で「インターネット」に変換するのは SKK ぐらいなんだべか。↓を読んで、ふと。

>>470
> ただ、「インターネット」は「innta-netto」だし、「ウィンドウズ」は「Uxinndouzu」だし、「マイクロソフト」は「maikurosofuto」だし。

>>476
なんかあれですよね。
mozc-utが色々揉めたので色んなところが影響を受けたんじゃないかと。
>>478
mozc-utの頃は良かったんですよね。
昔のUbuntuのBBS等の書き込み見てるとmozc-ut入れて変換できるようになったよとか書いているので。
今でも、Ubuntu使ってる人はmozc-utビルドして使ってるみたいですね。
Fedoraとか聞かないんですが、日本語入力とかしてないのかな？

今回作った辞書はやったことも含めて、もし必要であればアップロードも可能です。
アップロード先は教えてください。
登録字数：45936
元データ：https://github.com/KEINOS/google-ime-user-dictionary-ja-en?tab=readme-ov-file

昔、中村主水が一発で変換出来た事に感激した思い出
SKK だけど。

中村主水

libkkc + ibus でも一発でしたw

開発者がいい仕事してますね

MacのTahoeの上のVMwareFusionProの上のUbuntu 25.10で
キーボード、IM設定グシャグシャになって、chatgptに
相談してUTM上でUbuntu 24.10でJapanese(OADG109A)キー配列で
Macの日本語JIS配列キーボードで記号が漏れなく打てるから
とそれにして、システム全体の日本語化はまたIMが崩れるから
ダメ！！と言われてそうしてる。
半角英数<=>日本語ローマ字入力の切り替えは、option+spaceで。

https://xxup.org/I9sff.png

https://xxup.org/Qkuoa.png

AI は知恵遅れ

お猿さーんだよー

libkkc を最近始めた人はディストリビューションによってskkdic が分かれているから他に辞書が無いかも見ときなよ。
skkdicで SKK-JISYO.L しか入らないのが Debian で skkdic-extra が別にある。
Fedora は skkdic で SKK-JISYO.L 以外も入る。

>>486
ありがとう、それ気づいてるよ。
この辞書の文字コードとか色々あるんだよね。libkkcの辞書って文字コードは何で保存するのが正しいのかな？

/usr/share/skk/SKK-JISYO.JIS2: ISO-8859 text, with very long lines (515)
/usr/share/skk/SKK-JISYO.JIS2004: ISO-8859 text
/usr/share/skk/SKK-JISYO.JIS3_4: Non-ISO extended-ASCII text, with very long lines (418)
/usr/share/skk/SKK-JISYO.L: ISO-8859 text
/usr/share/skk/SKK-JISYO.L.unannotated: ISO-8859 text
/usr/share/skk/SKK-JISYO.M: ISO-8859 text, with very long lines (337)
/usr/share/skk/SKK-JISYO.ML: ISO-8859 text
/usr/share/skk/SKK-JISYO.S: ISO-8859 text
/usr/share/skk/SKK-JISYO.assoc: ISO-8859 text
/usr/share/skk/SKK-JISYO.china_taiwan: ISO-8859 text
/usr/share/skk/SKK-JISYO.china_taiwan.header: ISO-8859 text
/usr/share/skk/SKK-JISYO.edict: ISO-8859 text, with very long lines (372)
/usr/share/skk/SKK-JISYO.edict2: Unicode text, UTF-8 text
/usr/share/skk/SKK-JISYO.emoji: Unicode text, UTF-8 text, with very long lines (1618)

--いっぱいあるので省略--

あと知りたいのはLibkkcの辞書はどこにconfigあるんだろう。
guiだとlibkkcはこうなってます。guiしか設定できないのかな？
"あいおいちょう /相生町/愛生町/相生丁/"とか変換できるので、SKK-JISYO.geoが有効になってるのはわかるんですが。
https://i.imgur.com/AoILyX9.png

sskはこうなってるんです。うちの環境だと。
でもshift押しながらうまく変換できないので確かめられない。
これ本当に難しい。
https://i.imgur.com/Yd8cyAA.png

Jack has A bat and two balls

この説明だったり
https://chienomi.org/archives/livewithlinux/885
この辺り
/usr/share/fcitx5/kkc/dictionary_list

>>490
ありがとう。
きびしいね。やっぱりmozc-utを自前で何とかするしかないんだろうなぁ。

SKK の方はこんな問題だろう。情報が古いから今とは違うだろうけど
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0175

DDSKK は気に入ってるのに fcitx5-skk の挙動がポンコツ過ぎて嫌だわあ
アルファベット入力中に ctrl キーを押した途端に backspace をはじめキー入力を受け付けなくなってしまう
これがなければ常用するんだがな

>>493
似てたりしますか？
https://github.com/fcitx/fcitx5-skk/issues/27

fcitx と mozc は要らない子

>>493
> アルファベット入力中に ctrl キーを押した途端に backspace をはじめキー入力を受け付けなくなってしまう

「アルファベット入力中」って、例えば「/alpha」と入力するとこの↓状態?

$ ▽alpha

であれば [ctrl] キーも [BS] キーも、うちでは利く。

$ dpkg -l fcitx5-skk | tail -n 1
ii fcitx5-skk:amd64 5.1.1-1build3 amd64 Japanese SKK input engine for Fcitx5

hazkey 0.2.1が出てるよー

>>497
ありがとー

>>497
うーん、こんな感じで動かないかとか色々やっては見たけどもダメだな〜
debianパッケージをrpm系で…

spotify-launcher
https://github.com/kpcyrd/spotify-launcher

ばーじょん
Mozc-3.33.6089.102+24.11.oss

>>500
どう変わりましたか？
教えてください、お願いします。

https://github.com/google/mozc/commit/8f92cd985cba2fd009545963698f4df7424bec56

こっちも期待

karukan-im ローカルLLMを使った日本語入力システム
https://github.com/togatoga/karukan

>>503
教えてくれてありがとうございます！
Hazkey使えなかったけど、これでLive変換戻ってきました
Mozcより変換効率いいよね〜

rust で書かれているのか

karukanで"Hugging Face"を知ったけど、このプロジェクトもすごいな。
将来のタチコマの元になるデーターがいっぱいある。

xubuntu daily入れ直したら
fcitx-mozcとibus-mozcとmozcがない
とにかくmozc関連すべてないsynapticで
とりあえずfcitx5-anthy入れといた

karukan-imは今二つ謎？

・全角記号ってどう出すんだろう？ ／、⋯ とか
・"Right Super 英数字/カタカナ → ひらがなモードに復帰" このRightSuperがないなぁ‥

>>508
まだ機能もソースもよくわかってないのですが
全角記号は辞書ファイルに載せてあげる必要がありそうな気が...

目標が私用ですけど、JISかな入力できるようにkarukan-imに修正を入れてみて
かな漢字変換自体は、なんとかできるようになりました

有望なIMEがFcitx5向けばっかで悲しぃ😢

Waylandのせい
もうWayland強制が近づいてきてる

>>509
なんかもう少し情欲しいですね
ソース見る方が早いのかな？
ビーム幅とか

>>508
>>509だけどユーザ辞書経由で／…を出せるようになったよ

- mozcで使っていたユーザ辞書をmozcの辞書ツールからエクスポート
- cargo run --release --bin karukan-dict -- build mozc_export.txt -o dict.bin
- 出来上がったdict.bin を ~/.local/share/karukan-im/user_dicts にコピー

>>513
そうなんですね
自分は学習辞書(learning.tsv)をなんとかするのかなと思って調べてました
githubのissuesにも下記がありますので、楽しみに待ってみようかと

"記号や全角・半角の変換候補パターンを増やす"

メモリ消費800MB以下。脱GUIで省メモリな日本語環境の可能性を探る
Ubuntu Japanese Team/日本仮想化技術株式会社 水野源
2026年3月7日
https://pc.watch.impress.co.jp/docs/column/ubuntu/2091326.html

>>515
パーツ高騰で新調できない！←わかる
古いマシンを復活させるぞ！←わかる
GUIは重すぎる！←いつの時代のPCだよ…

>>515
面白い記事で新しい情報に自分的に得るものがあったけど、
自分の鯖運用にCLIでWebを見たり
動画再生をする必要性を感じるかと言うと…

普通にCLIで鯖運用するならSSH接続で管理して
その接続するクライアントPCでブラウザ開いて動画見るわね…
セキュリティ的な視点からも

>>510
何で？中国父さん様々だが

>>518
Fcitxが嫌いって訳じゃないんだけど、Gnomeだといまいちしっくりこないというか…
まぁ、GnomeがIbus決め打ちじゃなくKDEみたいに柔軟に対応してくれたらいいんだけどね

3.33.6133
https://github.com/google/mozc/commit/c9163b6bb1010671781b8acd358b025c519fc1e0

Arch系でfcitx5-cskkを導入できたかた、お力を貸してください

$ fcitx5-diagnose
**アドオン `Cskk` の `fcitx5-cskk` に必要な次のライブラリが見つかりません。**

libcskk.so.3

で詰まっています。

やったこと：
yay -S cskk
yay -S fcitx5-cskk

環境：
CachyOS Linux
KDE Plasma バージョン: 6.6.3
カーネルバージョン: 6.19.10-1-cachyos (64 ビット)
グラフィックプラットフォーム: Wayland
プロセッサ: 4 × Intel® Core™ i5-4300U CPU @ 1.90GHz
メモリ: 4 GiB の RAM (3.7 GiB 使用可能)
グラフィックプロセッサ: Intel® HD Graphics 4400

>>521
少し調べてみた
($ yay -S fcitx5-cskk-git)

mkdir cskk
cd cskk
git clone https://github.com/fcitx/fcitx5-cskk.git

README.md にある手順でビルド
cd fcitx5-cskk
mkdir build
cd build
cmake ..
make
sudo make install

cd /usr/cskk
ls -l
sudo cp -r libcskk.so* ../

sudo ldconfig
reboot

libcskk.so.3の問題はクリアされて、ローマ字入力はできるようになったが
辞書ファイルがみつからないせいなのか漢字変換はできなかった

×　cd /usr/cskk
❍　cd /usr/lib/cskk

>>522
ありがとうございます！cskkで入力できるようになりました

>>514
karukan-imのフォーク版が公開されていた
https://github.com/riq0h/karukan

記号辞書などの辞書や、本体の更新で入力しやすくなったよ

いいね

>>525
お知らせ有難うございます。
早速、使ってみます。

gitで開発者に要望出すのってどのくらいのレベルだと嫌がられますかね⋯
ソフトウェア開発になんにも貢献できてない一般ユーザーからなんですけど

未変換文字列に対してdeleteするとき、かな漢字テーブルが
"s h o" = "しょ"
だと「しょ」が消えて
"s h o" = "し" "ょ"
だと「ょ」だけが消える
みたいな挙動だとうれしい。uimがそうだったので

でもこれって他の人への影響が甚大だから無理そう

違いが分かりません

わからないけど、uimとfcitx5では挙動が違うとかでは?
どの入力メソッドなのか不明だけど……

Ibusの導入方法が少し変わったみたい
自動起動に使うコマンドはibus-daemonからibus startに変更
Text Input v2をサポートしてるWaylandコンポジターはオプションに --type=wayland 使用可
Waylandは基本的に環境変数の設定は必要ないけど、上手く機能しない場合は$HOME/.bashrcに↓を追加
export GTK_IM_MODULE=wayland
export XMODIFIERS=@im=ibus
export QT_IM_MODULES=wayland;ibus
export QT_IM_MODULE=ibus

SwayでIbusが不安定だから調べてみたらSway公式の推奨アプリのリストにIbus入ってなかったわ…
そんな訳でFcitx5に乗り換えたというかFcitx5-AnthyってQtなしで動くのな
すごく安定してる

Fcitx5入れたついでにKarukan試してみた
ヌルヌル変換できるし辞書編集も楽で使いやすいな

ibus-skkではウィンドウごとにカナ/英数モードを覚えてくれないのが不満だったが
fcitx-skkでは覚えてくれていい感じ

fcitx5-skk

>>534
IBusもウィンドウごとに入力ソースを別ける設定があったと思う

fcitx5-skk (5.1.6-1) で「寝落ち」を登録しようとして「NeoTi」と入力したら
「▼ねお*ち【】」と辞書登録モードになり「▼ねお*ち【寝落ち】」と入力し確定
user.dict には「ねお*ち /寝落ち/」と登録されているものの
「NeoTi」と入力したら、また辞書登録モードになってしまいました
また user.dict に登録された「寝落ち」を削除しようとして「NeoTiX」と入力したら
「▼ねお*ち【▽x】」となりうまく削除できませんでした
何が悪いんだろう？

なおSKK-JISYO.Lには * のついた送り仮名って登録されてないみたい

日本語入力めっちゃ退化してるよな
30年前のATOK変換が文法、統語的に綺麗でよかった

anthy がクセがあって嫌って話？

そもそも日本語入力がコンピュータとの相性最悪なんだよな
どんなに優れた入力機構であろうと変換が期待通りにできたか確認する必要がある
変換のいらない英語とかならタイピングが完璧なら確認なく期待通りに入力できる

日本語でも漢字直接入力のT-Codeなどがあるという人もいるかもしれないが
学習コストが高すぎて標準になる可能性はゼロだ

脳で考えていることをそのまま入力できるようになればまた話はかわるが
いつになったら実現できることやら

じっくりと学習させた辞書を使い、ある時点で学習機能を切るのもひとつの手なのかもしれない
例えば「こうしょう」を変換するとき、最初は「交渉」次は「高尚」だと人間が学習する作戦だ
なんでも「こうしょう」には50種類ほどの同音異義語があるらしいが、よく使う変換を
覚えてしまえば、覚えた変換を使っている限り変換結果を確認する必要がなくなる

>>537
user.dict には「ねおt /寝落/」と登録されるべきとちゃう?

>>542
その通りです
ただし今回の場合は自分が間違えて送り仮名も含めて登録しているので送り仮名があるのは正常です
>「▼ねお*ち【】」と辞書登録モードになり「▼ねお*ち【寝落ち】」と入力し確定

また「ねおt」でなく「ねお*ち」になっている理由はわかりませんが
ibus-skkでも、自分で追加登録した送り仮名つきの単語は「ねお*ち/寝落/」のようになってました
なおSKK-JISYO.Lのようなシステム辞書にある送り仮名つき単語は「わりこm /割り込/」のようになっています

>>543
うちの fcitx5-skk 5.1.10 版では、
AkioTi という読みで「秋落」を入力すると user.dict は「あきおt /秋落/」
KomaoTi という読みで「駒落ち」を入力すると user.dict は「こまおt /駒落ち/」
となり、読みにアスタリスクは入らなかった。

>>544
最新版での確認ありがとうございます
もしかするとuser.dictを管理しているのはfcitx5-skkではなくlibskk0っぽいので
自分が使っていたlibskk0(1.0.5+git20240901-2)がアスタリスクがつく原因なのかもしれません

>>541
なるほど 変換候補の順番がが固定化されるのか 良いかもしれない

>>544
やはりlibskkが原因で1.0.5の次のリリースの1.1.0で修正されたようです

Unexpected dictionary registration behavior with okuri-ari entry #77
https://github.com/ueno/libskk/issues/77