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),
 
Anyone know how to bring up fcitx 5 in xrdp context? It seems the environment variables in a remote desktop are different than in a local one.
 
bxbzq there are three systems in play here:
(1) The computer in front of you that is connecting the RDP-source computer
(2) On the RDP-source, there is an X11 server
(3) On the RDP-computer, there is an X11 client

(2) and (3) may be the same computer.
Where are you running the fcitx5?
 
It's the computer running XRPD server (RDP-source in your term) that I'm connecting to remotely has fcitx installed, and I want to bring up the fcitx to work with tools like libreoffice on the RDP-source computer.
 
bxbzq, I presume that means you're running the X11 server and client on the same machine.

  1. Have you tried running xev on that machine and making sure the keystrokes to activate the IME are getting through properly?
  2. Can you verify the IME is set up correctly?
    1. If you have direct access to the machine, try to trigger the IME with its own keyboard
    2. Is this a Qt issue? You mention LibreOffice which is Qt. Do you have fcitx5-qt6 installed? Do gtk/gnome apps work?
  3. If you have a DE like Gnome or KDE Plasma, can you change the input method from an icon in the notification area?
 
Thanks all my FreeBSD friends for your advice! I decided in the end to fall back to ibus-anthy which for some reason works with all the apps I tried it with. They say mozc is the more sophisticated input method, but I guess I can live with a less perfect one that works with all my apps rather than one which only works with some of them (!).

FYI I got some advice from an ibus-anthy user over in the GhostBSD forum and put the following in my .xprofile:

export XIM=ibus
export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export XIM_PROGRAM="ibus-daemon"
export XIM_ARGS="--daemonize --xim"

Thanks again, everyone!:)

ghostbsdibus-anthy.png
 
jwillia3 said:
bxbzq, I presume that means you're running the X11 server and client on the same machine.

  1. Have you tried running xev on that machine and making sure the keystrokes to activate the IME are getting through properly?
  2. Can you verify the IME is set up correctly?
    1. If you have direct access to the machine, try to trigger the IME with its own keyboard
    2. Is this a Qt issue? You mention LibreOffice which is Qt. Do you have fcitx5-qt6 installed? Do gtk/gnome apps work?
  3. If you have a DE like Gnome or KDE Plasma, can you change the input method from an icon in the notification area?
Click to expand...
The DE is xfce. If i log into DE locally using startx, all apps I use work with fcitx, including libreoffice, firefox, mousepad, xfce4-terminal, etc.
While remotely via RDP, only libreoffice doesn't work with fcitx, the othe apps work just fine.
 
As for me, I can only do QT stuff with fcitx5-anthy--on VMS and such, I usually download featherpad to test it. (Much smaller than libreoffice). ChapinTokyo, glad you found a solution that works for you. I used to use ibus, but stopped around FreeBSD-10 when it began having issues for me, and I needed a little script each time I used it. (This was on a small window manager, not XFCE4 or Mate).
 
Does inputs to libreoffice or any other Qt6 apps WITHOUT fcitx enabled (ASCII only inputs) work normally? Does remote keymap look correct?
If so, possibly forcibly setting keymap in (maybe) ~/.xsession could help.
If I recall / understand correctly, configurations in ~/.xinitrc are ingnored on xrdp session and all configurations needs to be written in ~/.xsession instead.
 
Ok. In my case, it's /usr/local/etc/xrdp/startwm.sh taking effect. Write following lines to ~/startwm.sh I can bring up fcixt in libreoffice.
Code: 
export XIM_PROGRAM fcitx
export XIM fcitx
export  GTK_IM_MODULE fcitx
export  QT_IM_MODULE fcitx
export  XMODIFIERS "@im=fcitx"
 
You must log in or register to reply here.
Back
Top