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=3Dyes (i=
.e.,
prioritize user experience)

On Thu, 2023-03-02 at 09:42 +0000, Simon McVittie wrote:
> Control: tags -1 + moreinfo
>=20
> 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/de=
fault-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 preferre=
d
> > mozc over anthy. So the hardcoded value should be adjusted for our
> > users.
>=20
> 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.=20

Before going into that kind of discussion, I would like to draw attention t=
o
general performance perception and some technical points.

* Why mozc:
In general, mozc tends to provide better suggestions for the possible choic=
e of
input conversion choices than ones provided by anthy.  This may be the reas=
on
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 th=
e
code for mozc is written for the little endian system only.  (mozc's C++ he=
ader
file structure and shipped data requires specific endianness.)

Also data used for obtaining conversion proposals are more opaque for mozc.=
=20
Data for anthy is more intuitive for modification than that of mozc.  Neith=
er
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!
>=20
> 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 riscv6=
4,
> 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
>=20
> Please talk to upstream about this: if mozc is a better default for Debia=
n,
> 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=C2=A0which is a=
bout
> switching the default from kkc to anthy, and
> https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/104=C2=A0whic=
h is
> older and refers to kkc as being the default.

 * kkc and anthy are both in GPL: kkc was intended to be improved replaceme=
nt of
anthy by RH developer.  Its resulting performance was not convincing to rep=
lace
anthy.  Anthy was by Japanese government sponsored and it's last updates wa=
s
gathered and organized by DD (muto-san).

 * mozc is mostly BSD-3-Clause with its opaque learned data being BSD-3-Cla=
use-
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 o=
nly
provided as a data dump.

> On Wed, 22 Feb 2023 at 15:09:15 +0900, [email protected]=C2=A0wrote:
> > =C2=A0 Thus with attached patch, gnome-initial-setup will not
> > =C2=A0 show label for mozc-jp as "=E6=97=A5=E6=9C=AC=E8=AA=9E (Mozc)" b=
y default.
>=20
> What would be the best label to be displayed there?
>=20
> What is actually displayed instead?
>=20
> > =C2=A0 To display label correctly, fetch_ibus_engines_result must be ca=
lled=20
> > =C2=A0 in advance.
>=20
> 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.
>=20
> Probably the best we can do there is to hard-code a special case for
> mozc-jp.
>=20
> =C2=A0=C2=A0=C2=A0 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) seem=
s 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.=20

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 goo=
d
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 Japane=
se
desktop task unless you like lisp over python.  Our default desktop needs i=
bus
for easy configuration.  Unless we make consistent choice for the default, =
it
gets messy.