How to input Japanese using fcitx-mozc? 日本語入力への切り替え出来ず...

scottro said:
T-Aoki, in the link for Ken Dechui's overlay, he writes that it doesn't work well in 15.0-CURRENT. Obviously, 15.0 is no longer CURRENT, but are there still problems with it. (ChapinTokyo, apologies for hijacking the thread, but it's only one question. ゆるして　くださ)い。
Click to expand...
It's remaining old description and already not applicable (applicable to limited range of commits, so kept for anyone accidentally built / installed the affected old main, maybe). See the last part of README (README.md that are shown on browsing the URL I've linked previously).

I'm now on stable/15 and having main (aka 16-CURRENT) on another physical SSD, his overlay is working fine on both now for months. So no worries. ;)
 
From a user's perspective, there are three differences between Ken Deguchi's mozc and ports' mozc.
Latest version, fcitx5-mozc and ut dictionary.
It will take a little while to build.
I think the combined build time of bazel8, mozc-server, mozc-tool, and fcitx5-mozc will exceed that of Firefox.
 
Charlie_ said:
From a user's perspective, there are three differences between Ken Deguchi's mozc and ports' mozc.
Latest version, fcitx5-mozc and ut dictionary.
It will take a little while to build.
I think the combined build time of bazel8, mozc-server, mozc-tool, and fcitx5-mozc will exceed that of Firefox.
Click to expand...
Yes. bazel (even when bazel7 was used for this overlay) causes much longer build times than previous build infrastructure.
As heared from Ken DEGUCHI before via private email before, this was because mozc dropped supports for previous build infrastructure.
(Would be around Nov., 2024 looking back my mailbox. In-tree version is much older.)

And worse, bazel attempts to download some external components of it (maybe like npm for node.js and crates for Rust?) on build time, he said a tricky way was needed to allow building on poudriere, which by default prohibits downloading after fetch phase (can opt-out it, though).
 
I just went and played with fcitx5-mozc on an Arch Linux bhyve vm to see if it was likely to really affect me. I've found that for my (extremely limited these days) use of Japanese, it's not going to make much difference. So, for now at least, I'll go back to being my usual lazy self and wait till it gets into installable packages. Though I should definitely add mention of it to my page on Japanese in Linux/*BSD page.
 
scottro said:
I just went and played with fcitx5-mozc on an Arch Linux bhyve vm to see if it was likely to really affect me. I've found that for my (extremely limited these days) use of Japanese, it's not going to make much difference. So, for now at least, I'll go back to being my usual lazy self and wait till it gets into installable packages. Though I should definitely add mention of it to my page on Japanese in Linux/*BSD page.
Click to expand...
Of course it's on you which to choose.
But I've found PR 288313 andPR 289551 just now.

Unfortunately, Ken DEGUCHI's work would require once or more per month updating as of distfiles for dictionary, which are converted and built into mozc-server binary. This can be (possibly) decreased (as ports side) to per month or fewer by keeping UTDIC option disabled, but another is seemingly mandatory (Japanese zipcode data, 2 files overwritten on updates upstream).

In current in-tree version, the zipcode data files are hosted as a dated copy, but quite outdated.

Not sure it's acceptable (as portmgr and secteam's perspective) or not, but making ports to fetch (at least) problematic, overwritten-by-upstream dictionary sources including UTDIC's ones (if I recall correctly, at least JAWIKI) into fixed place somewhere like ${PREFIX}/share/dic-sources/, BUILD_DEPEND'ing on the port and use fetched data as dictionary sources could help.

For bazel, works are in progress at PR 287546.
 
Another problem with mozc is that mozc-tool depends on qt5.
I think qt5 will be removed before fcitx.
mozc will need to update qt5, python311, fcitx related components or migrate to newer versions in the near future.
 
And for python, master (parent) port japanese/mozc-server [japanese/mozc-tool is a slave (child) port of it] has USES line below on Ken DEGUCHI's version.
Code: 
USES=    compiler:c++20-lang gmake java:build localbase ninja:build pkgconfig \
    python:3.10+,build shebangfix tar:bzip2

It may be because he started working on the time 3.9 was the default.

So I think it would automatically chase default, as current default is 311 and I cannot find 310 in my local poudriere repo.

And in-tree version has python:build in its USES line. So it should simply chase default.
 
The more I read, the more I decide to stay with fcitx5-anthy till mozc becomes a package :). That's not any sort of insult, it just seems that it probably requires someone with more skill and knowledge than I have to make it work, especially when the type of thing I write is (to use yesterday as an example)
お誕生日おめでとうございます!! 姉御がんばって!　　(I picked up anego from some anime or yakuza movie and it really amused my father in law, so now I use it with her. My niece was in Japan, while my wife was there, and was introduced to the family and I told her to use it too, but my wife stopped her. My niece speaks no Japanese so wouldn't have gotten it),
 
You must log in or register to reply here.
Back
Top