ueno / libkkc Goto Github PK

Originally reported in Fedora 31 bugzilla; https://bugzilla.redhat.com/show_bug.cgi?id=1736028

Seems libkkc build is failed with the latest vala 0.45.3 .

お世話になっております。

各かな漢字変換ソフトに
ユーザー側で
まったくユーザー辞書の学習をさせずに

たとえば
「ゆうゆうはくしょ」
で変換を試した場合

ibus-kkc「ゆうゆう白書」
ibus-mozc「幽☆遊☆白書」

と変換されます。

ibus-kkcが不完全な変換なのに対して
ibus-mozcは「☆」マーク付きでの完璧な変換です。

SKK辞書の公式の方たちは
こういった「simeji」(スマホ向けかな漢字変換アプリ)のような
辞書の開発には消極的な方針のように見えます。

仮にSKK辞書を僕がForkしたら
そのFork部分「も」
libkkcで採用していただくことはできませんでしょうか？

Ubuntu Linuxがibus-kkcを標準搭載できずibus-mozcの標準搭載を続ける理由
Fedora 34が標準搭載IMEをibus-kkcからibus-anthyに乗り換える理由

また開発者としての立場ではなく
ユーザーとしての立場の僕が
ibus-kkcの変換に大きなストレスを感じる理由

現行のSKK辞書のボキャブラリの貧弱さ

「クラウド超変換」機能もあり
ボキャブラリが豊富な「simeji」レベルのlibkkc向けのSKKのFork辞書を
僕に作成させていただけませんでしょうか？

また、
このSKKのFork辞書の作成のために
Gitだけによる
辞書更新だけではなく
プログラマなど開発者以外の人も
誰でも参加可能な
つまりGitが使えない人でも
誰でも参加可能な
Webベースの
かな漢字変換の候補を
登録・SKK辞書フォーマットへの自動変換
できるWebアプリを
僕がサーバサイドも含めて
開発したいのですが･･･

Webベースで
みんなから
登録された
かな漢字変換の候補につきましては
もちろん
僕のSKKのFork辞書への登録の最終確認は
人間の目で行います。

いかがでしょうか？

僕にlibkkcの辞書のボキャブラリの発展に協力させていただけませんでしょうか？

どうか
よろしくおねがいいたします。

I installed this on Fedora 30 using input sources but its not working with steam, with normal applications like text editors and firefox its working but with steam and some other applications input is not working.

It seems that some years ago https://bitbucket.org/libkkc/libkkc-data existed.
One libkkc-data tarball is available on https://github.com/ueno/libkkc/releases, but no git repository for libkkc-data can be found.

Any chance of a new release?

Inputting "vu" in hiragana produces 「う゛」 HIRAGANA LETTER U + KATAKANA-HIRAGANA VOICED SOUND MARK, instead of the more correct (and better-looking) 「ゔ」 HIRAGANA LETTER VU. Not a major problem since 「ゔ」 isn't often used in hiragana, but still a bit inconsistent.

If I understand the code correctly, this would need minor changes in libkkc/rom-kana-utils.vala (line 71) and several data/rules/*/rom-kana/default.json files.

I could probably make a pull request, but I have no idea how those work.

はじめまして。
ibus-kkcで「ローマ字」入力ではなく「かな」入力の設定の場合
Shiftキーを押しながら「わ」を押しても「を」にはならず「わ」が入力されてしまう問題があります。
ibus-kkcで「ローマ字」入力ではなく「かな」入力の設定の場合
「を」を入力する手段が見当たりません。
ご指導お願いいただけませんでしょうか？

I'm not sure whether to report this here or in ibus-kkc (which is the frontend I use), but as the rom-kana conversion appears to be done here, I feel this to be the most reasonable choice.

When typing k b BS, I'd expect to return to the state as if I had only written k, so that pressing a would create か, or backspace would erase the k. This doesn't appear to be the case: k b BS a gives kあ, and when typing k b BS BS, the second BS appears to have no effect and I need a third BS to erase the k.

I'm aware that there's an option to remove partial inputs (so that k b is equal to just b), but I find that to be rather annoying.

Also, currently typing h y o BS erases the entire ひょ. Would it be possible to instead return to an un-kanaified hy, so that h y o BS a gives ひゃ instead of あ? (Possibly as a config option or something, since some people might like the current behavior)

It would seem this project went out of scope for its maintainer, yet I've got a question that likely any native speaker could answer.
In libkkc/rom-kana-utils.vala WideLatinTable contains quite a few chars that aren't from the unicode range for wide latin. Are those entries correct or were they simply semi-random substitutes ?

libkkc currently requires python2 for sortlm.py and genfilter.py

Would it be possible to make them Python 3 compatible?

GPLv3 is not so friendly to make use of it for in-process plugin. Would you mind to relicense it to something like LGPL ?

For example:

>> れいわ
0: <令/れい><わ/わ>

The correct result should be:
<令和/れいわ>

>> れいわじだい
0: <れ/れ><岩/いわ><時代/じだい>

The correct result should be:
<令和/れいわ><時代/じだい>

I am using libkkc 0.3.5+git20190809.b2e5a15-2.1.

My main keyboard is the standard Brazilian Portuguese. It would be perfect if libkkc allowed me to use that as the default Latin alphabet!

Hi,

I am enabling 'ppc64le' build on travis-ci along with amd64. And updated the .travis.yml file and added arch:ppc64le along with amd64. But getting below error in one of the ppc64le build job while executing the command $docker exec $CONTAINER su - user sh -c "cd /srcdir && ./configure $BUILD_OPTS" from .travis.yml file.

"checking for suffix of executables...
checking whether we are cross compiling... configure: error: in /srcdir': configure: error: cannot run C compiled programs. If you meant to cross compile, use --host'.
See `config.log' for more details
The command "docker exec $CONTAINER su - user sh -c "cd /srcdir && ./configure $BUILD_OPTS"" exited with 1.
0.19s$ docker exec $CONTAINER su - user sh -c "cd /srcdir && make V=1 && touch po/libkkc.pot && make check V=1";
make: *** No targets specified and no makefile found. Stop.
The command "docker exec $CONTAINER su - user sh -c "cd /srcdir && make V=1 && touch po/libkkc.pot && make check V=1";" exited with 2.
after_failure
0.15s$ docker exec $CONTAINER su - user sh -c "cd /srcdir && cat tests/test-suite.log"
Done. Your build exited with 1."

For complete error log please see this link : https://travis-ci.com/github/sanjay-cpu/libkkc/builds/183214940

Please have a look into this.

Thanks !!

When typing じどり、you don't get 自撮り as a candidate.

As a temporary fix, is it possible to add words individually to dictionaries?

Looks like last version build fails with latest gcc 14.x which is now used in fedora rawhide.

v0.3.5...master shows +60 commits since last version.
Is it possible to release new version? 🤔

I feel that since there is no conflict, it shouldn't be a problem to accept both "du" and "dzu" for づ. With the default rom-kana mapping, when you type "dzu" you get ず, which is frustrating. I get that experienced native Japanese speakers would know to use "du" instead, but I had to visit the json to figure this one out.