Re: Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Hi,
This is very convoluted issue.
Disclaimer: I use (n)vim and anthy and voted for non-free-firmware=yes (i.e.,
prioritize user experience)
On Thu, 2023-03-02 at 09:42 +0000, Simon McVittie wrote:
> Control: tags -1 + moreinfo
>
> On Sat, 28 Jan 2023 at 16:46:35 +0900, YOSHINO Yoshihito wrote:
> > As mentioned in Bug #984875, gnome-initial-setup's default choice of
> > input method is hardcoded in the dependent libgnome-desktop-4-2 package.
> > The Japanese one is anthy
> > https://sources.debian.org/src/gnome-desktop/43.1-1/libgnome-desktop/default-input-sources.h/#L39
> > preferred by upstream (Fedora/Red Hat) perhaps because its code base is
> > simple and easy to maintain, while this is not suitable for most Debian
> > Japanese users, who use mozc because of its better conversion quality,
> > thus task-japanese-gnome-desktop and task-japanese-desktop has preferred
> > mozc over anthy. So the hardcoded value should be adjusted for our
> > users.
>
> Is there consensus among Japanese-speaking users of Debian that mozc is
> a better default for all Japanese speakers, including new users who are
> not familiar with GNOME or Debian?
Choice of input method engine and its framework are hot topics without easy
unanimous agreements.
Before going into that kind of discussion, I would like to draw attention to
general performance perception and some technical points.
* Why mozc:
In general, mozc tends to provide better suggestions for the possible choice of
input conversion choices than ones provided by anthy. This may be the reason
why people like mozc than anthy.
* Why anthy:
In debian/control, mozc source package comes as:
> Architecture: i386 amd64 armel armhf arm64 riscv64
while anthy doesn't have such limitation. My vague memory tells me that the
code for mozc is written for the little endian system only. (mozc's C++ header
file structure and shipped data requires specific endianness.)
Also data used for obtaining conversion proposals are more opaque for mozc.
Data for anthy is more intuitive for modification than that of mozc. Neither
are easy to do, though.
> I want to avoid changing this from anthy to mozc-jp, and then getting a
> second bug report from a different Japanese user saying that we need to
> change it back!
>
> Looking at #984875 and #983653, I also see a mention of mozc only being
> available on certain architectures: it's available on x86, ARM and riscv64,
> but not on mips*el, ppc64el or s390x.
Correct.
> How does this interact with the default being mozc-jp? Do we need to use
> a #ifdef to make the default be mozc on architectures that have it, and
> anthy on architectures that don't?
If we decide to propose mozc as preferred choice, that should be a possible
choice.
> I'm also concerned that mozc still depends on GTK 2 (a switch to GTK
> 3 was tried and then reverted, see #967641). This is OK for bookworm,
> but will probably not be supportable in Debian 13.
> > Upstream prefers ibus-anthy for Japanese input
>
> Please talk to upstream about this: if mozc is a better default for Debian,
> then it's probably also a better default for upstream.
>
> The only issue reports I could find upstream are
> https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/181 which is about
> switching the default from kkc to anthy, and
> https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/104 which is
> older and refers to kkc as being the default.
* kkc and anthy are both in GPL: kkc was intended to be improved replacement of
anthy by RH developer. Its resulting performance was not convincing to replace
anthy. Anthy was by Japanese government sponsored and it's last updates was
gathered and organized by DD (muto-san).
* mozc is mostly BSD-3-Clause with its opaque learned data being BSD-3-Clause-
with-ICOT-term. It's by google employee, if I recall. RH ppl may not like
opaqueness of learned data outside of their easy update. Learned data is only
provided as a data dump.
> On Wed, 22 Feb 2023 at 15:09:15 +0900, kenhys@xdump.org wrote:
> > Thus with attached patch, gnome-initial-setup will not
> > show label for mozc-jp as "日本語 (Mozc)" by default.
>
> What would be the best label to be displayed there?
>
> What is actually displayed instead?
>
> > To display label correctly, fetch_ibus_engines_result must be called
> > in advance.
>
> That's probably not possible: fetch_ibus_engines_result is called
> asynchronously with the result of a D-Bus method call, so it's already
> called as early as possible, and before that point we don't have the
> necessary information.
>
> Probably the best we can do there is to hard-code a special case for
> mozc-jp.
>
> smcv
In order to get mozc to be promoted to be more prominent position, we need to
make sure the maintainer of mozc feels comfortable. He (Iwamatsu-san) seems to
be making curating many patches and making patch to keep up with gtk3
transition. Gunnar also seems to be doing QA and regression checks.
Yoshino-san, did you check how mozc maintainers think about your proposal.
If they agree, I think promoting mozc for little endian platform may be good
idea for better user experience.
(But I will keep using anthy)
Osamu
PS: I don't understand rationale to keep uim over ibus still in some Japanese
desktop task unless you like lisp over python. Our default desktop needs ibus
for easy configuration. Unless we make consistent choice for the default, it
gets messy.
Reply to: