Arch Linux User Repository

To any and all future inquiries as to the nature of this package:

TL;DR this package is NOT a duplicate of extra/fcitx5-mozc, so please DO NOT report it as such.

To elaborate:

• Mozc operates with a server <-> client model.

• The extra/fcitx5-mozc package comes with both the Mozc server binaries and the Fcitx5-specific client binaries. This means that the package will conflict with any other Mozc client package, e.g. for IBus or Emacs.

• This package contains ONLY the Fcitx5-specific client binaries, and relies on mozc or mozc-ut for pulling in Mozc's server binaries. This means that a user can install this package alongside the equivalent IBus-specific and/or Emacs-specific packages (also currently present in the AUR) and enjoy Mozc across a variety of different but simultaneously installed environments (e.g. in the case of a shared PC with one user using KDE + Fcitx and another user using GNOME + IBus, or in the case of an Emacs user because of course Emacs comes with its own IMF >.>), with zero conflicts because all three of these client packages contain only the relevant client-specific binaries and share a dependency on mozc/mozc-ut for the server binaries.

• Unfortunately, even though this package does not in fact contain any UT patches (those are only applied to the mozc/mozc-ut server packages), it is named with a -ut suffix because of the existence of the extra/fcitx5-mozc package.

For more info you can read the Arch Wiki entry on Mozc.

If you're getting compilation errors (especially complaints about missing GCC headers) please delete your Bazel cache (~/.cache/bazel by default).

3.34.6239-2 works. Thanks!

Ah, you're absolutely right, I messed around a bit with the format of the install instructions and failed to notice the difference in filename between what the build process produces (mozc-addon.conf) and what I had that file installed as in the package (mozc.conf). I've reverted the install instructions to how they were in 6133.

Hi, after updating to 3.33.6239-1, mozc disappeared from the fcitx5 configuration tool and could no longer be added via "Add Input Method".

I'm not 100% sure of the cause, but my guess is a filename/reference mismatch in this version:

• The addon config is installed as /usr/share/fcitx5/addon/mozc-addon.conf, so fcitx5 would derive the addon id mozc-addon from that filename.
• However, usr/share/fcitx5/inputmethod/mozc.conf still references the old id mozc.

As a workaround, sudo ln -s /usr/share/fcitx5/addon/mozc-addon.conf /usr/share/fcitx5/addon/mozc.conf fixed it for me. Reboot after that and manually add mozc back to the input method list.

Remember to sudo rm /usr/share/fcitx5/addon/mozc.conf after the workaround no longer needed.

Thanks for maintaining this!

@therico I've recently come to a similar conclusion and, as a stopgap measure, in the 3.33.6079 update of mozc back in January I added a note that should be popping up at the end of the install/update process to inform the user about the existence of mozc-ut and what they should do to install and use it in place of mozc.

But probably the best overall solution, given the circumstances, is to remake these packages with only mozc-ut as the engine and abandon vanilla mozc altogether (which, after all, in its unpatched state is kind of useless).

It's something I'm planning to do in the near future, but for the time being I'm taking my time to make sure that the transition to the new packaging scheme will be as painless as it can get.

News to me as well. Perhaps the build process should at least warn the user if mozc is present (instead of mozc-ut) as I think most users are expecting the UT dictionary, at least that's why I historically started using this package!

Thanks for all of your hard work.

@Nocifer Understood. Thank you for accomplishing this difficult task and sharing the solution.

Yes, this package doesn't include the UT dictionary, it only includes the files required for plugging Mozc into the Fcitx framework. The actual Mozc engine comes with either mozc-ut (which includes UT) or mozc (which does not).

Yes, it would be better for this package to be called fcitx5-mozc, but 1) that name is already taken by the package in the official repos, and 2) when this family of packages began their life they were not modular and included the Mozc engine and so the UT dictionary as well, so the name did fit the description. After a while I split them to accommodate more use cases, and I tried to negotiate getting the "rights" to the fcitx5-mozc name from the (at the time practically abandoned; like, more than 2 years outdated) official package but without any success, so the name kind of stuck.

I've had some thoughts about revising a few things around how the packages work and in the process refreshing the naming scheme as well, but those plans were kind of cut short about a year ago, when some needless drama made me lose interest for a while. But now things seem to be back to normal, so I'll eventually (probably) find the time to do a revision.

I'm sorry if I misunderstood. Just to confirm: Does this package really not include the UT dictionary? If so, wouldn't it be better to use a suffix other than -ut?

@Nocifer I did what you told me to do and everything is working! ありがとう、兄貴！