まずは G-HAL 氏のところから。ご指摘感謝です。
Sun,23 Aug,2009
「|右|書き|と|」（|みぎ|かき|と|）
「|左|書き|を|」（|ひだり|かき|を|）
「書き」の名詞化？をすると助詞が付属しない。
とはいえ、仕様と言えば仕様だし、対応を考え始めるときりが無いと思う。
「右書き」「左書き」登録しました(辞書によると「みぎがき」「ひだりがき」と濁るらしい)。
動詞連用形名詞化の不足を補うのはずっと ToDo に入れっ放しのままで手が回ってません。申し訳ないです。
Wed,19 Aug,2009
「４か」とかで変換しても「４日」が出ない。当たり前な気もするけれど。
「か #JS 日」を登録してしまうと、たとえば「1か2かどっちか」が「1日2日どっちか」になってしまったりするので、「ついたち」「ふつか」「みっか」「よっか」のように不規則な変化をするものは「数詞+助数詞」の形で出すようにはせずに、そのまま一語で登録しています。
なので、やるとすれば「4か #T35 4日」と一語で登録することになりますが、それをやるとなると全角半角漢数字の全組み合わせを登録、また「4かめ #T35 4日目」のように「-日目」「-日前」「-日後」等々のケアもしなければならなくなるので、メンドくさい。
尤も、それは現状の「よっか #T35 4日」とかでも同じことなんですが。うーん、どうしよう…
取り敢えず、当面は「4にち」「5にちご」等で凌いで頂きたい。
複合語関連。
compound.t:
余分な空白が１つ：
らちがあ #K5 #_3ラチが_1あ #_3埓が_1明
読みがなの誤字？：
あびないはし #T35 #_4危ない_2橋
あと、のすけ氏のサイトで何年か前にリストアップされていた所が、一部治っていない。
該当部分の抜粋：anthy_dic_konosuke_memo.txt
「ず」「づ」、「いばらき」が「いばらぎ」になっている、あたり。
「がく」「がっ」は、どちらがよいのだろう？。
この辺のメンテナ／窓口は、一体何処なのだろう？
-----------------------------------------------------------
Wed,22 Jul,2009
web で make update_params の件を検索していたら、誤字修正をみつけた。
https://bugzilla.redhat.com/show_bug.cgi?id=509534
-----------------------------------------------------------
Wed,12 Aug,2009, alt-depgraph-090712
「誤判定」（ごはんてい）に助動詞？（する、した）が付かない。
alt-cannadic/gcanna.ctd と mkworddic/compound.t の両方で #T35 になっていた。
たぶん #T30 。
-----------------------------------------------------------
Wed,08 Jul,2009
「自動調整」（じどうちょうせい） #T35 なので、「する」が付属語にならない。
一応自分のところのは全部修正しました。
ちなみに、nosuke さんの memo にある「いばら *ぎ* てん 茨木店」は誤りではないようです。
【追記】9/28
間違えた。県名の「茨城」も大阪の「茨木」もどっちも濁らないのが正しいらしいです。以前調べて修正したのに、自分の頭の中だけ訂正されてませんでした(alt-cannadic-090921 ではちゃんと直ってます)。
つまり、nosuke さんのご指摘が正しかったわけです。ごめんなさい。
compound.t も窓口はいくやさんでいいはず。
redhat の bugzilla のは、いくやさんの所に直に報告が行っていると推測。
複合語は、ひょっとしたら品詞を持つ必要は無いのでは。この部分はちょっと意味が分からず。
構造を考えると、末端の単語の品詞をそのまま使えば良い筈だし、
末端の単語の品詞とは違う品詞を持つ様だと、それは複合語ではなくて別の単語だと思う。
salvan さん。
・「新入社員」他
・「安来節」他
・「炭坑夫」他
・「公器」
・「探訪記」(たんぼうき/たんぽうき)
登録させて頂きました。ご指摘有難うございました。
# 一部入れなかったもの/保留中のものがあります。
nosuke さん。
・「〜くなる」。
「一文節が長くなりすぎるから」だったか「発車の|ベルが|けたたましく|鳴る」のような「〜く|鳴る」のパターンを出せるようにするためだったか、もう忘れちゃいましたが、切るかどうか微妙なところなのでお好みでよろしいかと。
【関連する記事】
「みぎがき」「ひだりがき」の件は、また誤読をやらかしてしまい、お手数をお掛けして済みません。
「４日」は、登録しようとすると沢山あって面倒そう、と言う所で思考が止まっていました。
もっともこんなものは、「よっか」を「４か」とかタイプするような変な事をしなければ解決ですが。何故か指が勝手にタイプしてしまう……。
「みっか」「よっか」に関しては、「か #JSSUC*20 か」があるので、
「よっ #NN*5 四」と「か #JS*5 日」の様に値を小さくしておけば、
分解しても大丈夫そうな気もします。「ついたち」は無理ですが。
「茨城」「茨木」は、字が違う事に全く気付いていませんでした。
御指摘、解説、有り難うございます。
長くなるので一旦切ります。
>>構造を考えると、末端の単語の品詞をそのまま使えば良い筈だし、
>>末端の単語の品詞とは違う品詞を持つ様だと、それは複合語ではなくて別の単語だと思う。
さきに書いた時に、何の事だか判らないくらい、はしょってしまいましたが、
「compound.t の品詞の間違いが散発的に見つかるけれども、まだ気付かれていない品詞の間違いが沢山有るのではなかろうか。
それを人力で見つけて直すのは、相当大変、あるいは無理が有るのではないだろうか。
できるだけ簡単に、一括して、見つける／直す方法はないだろうか。」
という話です。
例えば「#T35 自動_調整」の場合、最後の単語の「調整」の品詞「#T30」を、複合語「自動_調整」に適用できるのではないでしょうか（別の見方をすると #T35 は間違い）。
また、「#KK 八重洲_無線」の場合、最後の単語の「無線」の品詞は「#T35」で、「八重洲_無線」の「#KK」とは一致しませんが、この場合は「八重洲無線」を１単語で「#KK」が適切ではないでしょうか。
でもそれだと、「やえす」で変換確定後に「むせん」で変換、とした場合に、前回確定内容の情報を活用出来ない問題が有りますが……。
今頃気付きましたが、「#JN 姓_名」の場合、「名」の品詞は「#JNM」で一致せず、駄目ですね……。
あと、誰がその作業をするんだ、と言う事は、全く考えていなかったりします。
UCS/Unicode と他の文字コード間で文字コードの変換を行う時、変換ソフト／ライブラリの種類によって変換後の文字が違ってしまう物があります。
そのような文字を utf8.t 以外から削除して、utf8.t に集めたのが、anthy-9100h.mkworddic_fix です。
ただし、波ダッシュ「〜」も変換ソフト／ライブラリが違うと各々別の文字に変換されてしまう事がありますが、単語数が多い為に挫折して諦めました。
これにより、
辞書の元データ → anthyの辞書 → anthy → uim → GTK/Qt → アプリケーション
と、渡されていく間ずっと UTF-8 で処理されるため、文字化けしなくなる筈……、
……と考えていたのですが。
（略）→ anthy → uim-xim → GTK/Qt → アプリケーション
（略）→ anthy → uim-xim → アプリケーション
（略）→ anthy → scim-anthy → GTK/Qt → アプリケーション
の場合、anthy から次に渡される所で UTF-8 から eucJP-MS/EUC-JP への変換が入ってしまう為、駄目かもしれません。
uim.el や ibus などは未確認です。
> 「か #JSSUC*20 か」があるので、
JSSUC は「助数詞につく接尾語」で、数詞に直接はつかない、かつ、多分 Anthy では効いてないので、関係ないですね。
でも、「か #JS*20 価 課」があった orz
「1か2かどっちか」→「1価2価どっちか」
ひぇ〜
ごめんなさい、ちゃんと確認してませんでした。
> 「よっ #NN*5 四」と「か #JS*5 日」の様に値を小さくしておけば、
その伝で行くと、「ふつ #NN 二」「むい #NN 六」「なの #NN 七」「よう #NN 八」も登録しなきゃいけなくなりますが、「ふつ」「むい」「なの」「よう」は多分後ろが「日」の場合にしか使われない読みだと思うので、誤変換を起こすデメリットの方が大きいと思ってます。
「よっ #NN 四」は既に登録されていますが、これは確か「四つ」を出すためだったと思います。これも分解せずに「よっつ #T35 四つ」「いつつ #T35 五つ」と一語で登録した方が良さそうですね。
# 一語で登録すると conf での「半角数字・全角数字・漢数字の候補の並び順」の設定が効かなくなったりして…
> できるだけ簡単に、一括して、見つける／直す方法はないだろうか。」
なるほど! それは思いつきませんでした。
compound.t で #T?? になってるものだけを対象にして、それ以外の(KK,JN,CN等)はそもそも数が少ない(1000弱)ので手作業で直せばいいでしょうね。
ただ、「読みの間違い」「漢字の間違い」「区切るか区切らないか」ということもチェックしないといけないと思うので、結局、一度全部見直す必要があるとは思ってます。
(ちなみに、cannadic改では、人名はすべて JN にして、JNS・JNM 等は使ってないです)
> 「anthy-9100h.mkworddic_fix の utf8.t は何なのか」の件
ご説明ありがとうございます。
サイトの説明を読ませて頂いたので、一応知ってはいましたが、充分理解できているかどうかはまだ怪しい…
scim-anthy は 1.2.7 で Anthy とのやり取りを UTF-8 でやるようになったと思うのですが、まだどこかに euc な部分が残ってるということでしょうか?
ibus は多分大丈夫でしょうね。
> (ちなみに、cannadic改では、人名はすべて JN にして、JNS・JNM 等は使ってないです)
ので、「#JN 姓_名」の場合も大丈夫です。
$ XMODIFIERS=@im=uim xterm &
で、「まるいちt」で丸数字の1を入力できたのを確認。
何か自分が勘違いしてる恐れが無きにしも非ずですが。
--------
It only supports input method with language whose character is
convertible into the working encoding of client application. In
short, if the client application (such as OpenOffice.org, tgif...)
is working with ja_JP.eucJP locale, you can use only Japanese input
methods (anthy, prime, skk...).
But if you use these client applications with UTF-8 locale (such as
ja_JP.UTF-8), you can use all the available multi-linguistic input
methods, and switch them dynamically.
--------
ということなので、多分 uim-xim も UTF-8 大丈夫な気がします。
元々 uim は多言語で使われることを想定して作られてるはずですし。
数字の読み方の変則につく接尾辞として見つかったのは、
「つ」「日」「日前」「日中」「日後」「日間」「日制」「日付」「日毎」「日頃」「日程」「日分」「日目」
わりとありました。
確かに一語にした方が誤変換は起こしにくそうですが、全部登録して、まかないきれるのか、登録・調整の負担が大きくなってしまうのではないか、不安が……。
＃ 残念ながら、conf での数字の並び順は「数字部分が辞書を使わなくても生成できる語」にしか効き目はありません。
＃＃ 変換結果「５日」／「五日」／「5日」に対して、読み仮名が「5にち」→効果有り、読み仮名が「いつか」→効果無し。
compound.t:
複合語を構成する各単語が alt-cannadic に載っていない場合、複合語の誤りか、alt-cannadic に追加登録した方が良いかもしれない単語か、どちらか、と言う点では自動化できると思いますが、
alt-cannadic に載っている場合でも、同じ漢字に複数の読みがあって間違えている場合、同じ読みで複数の漢字があって間違えている場合、間違った単語の組み合わせ方をしている場合などは、仰る通り人力でチェックしないと見つけられませんね……。
その他、複合語になると読み仮名が変わる特殊なケースもあるような気もしますが思い出せません。
scim-anthy:
すみません、更新するのを忘れて、古い版(1.2.4)を読んでいました。
最新の 1.2.7 の標準設定では、御指摘の通り一貫して UTF-8 になっていました。
uim-xim:
ソースコードの確認中です……。
uim を --with-anthy-utf8 でビルドすれば、御指摘の通り UTF-8 で動きます。
確認ありがとうございました。
この辺はしょうがないのでやるしかないですね。
> ＃ 残念ながら、conf での数字の並び順は「数字部分が辞書を使わなくても生成できる語」にしか効き目はありません。
あ、やはり…