Hi Andrew,
在 2026/6/18 10:42, Andrew Lee 写道:
Hi Boyuan,
Thank you for your response and the alternative patch. However, I
believe this change creates a few new issues while leaving the
original problem unresolved.
On Thu, Jun 18, 2026 at 4:11 PM Boyuan Yang <[email protected]> wrote:
As a follow-up, upstream clarified in
https://github.com/libpinyin/ibus-libpinyin/issues/565
that it is a bug in the upstream code. Following the upstream proposal, I have
prepared a new upload ibus-libpinyin/1.16.5-3 into Debian Unstable.
First, by forcing Traditional Chinese output, the libbopomofo loses
its original purpose, which was allowing bopomofo users to type
Simplified Chinese under zh_CN locale. Since libbopomofo is not
originally preferred by zh_TW users anyway, the engine is now less
useful for both target groups.
I don't think libbopomofo was intended for "allowing users to type Simplified Chinese under zh_CN locale". The upstream
stated clearly in https://github.com/libpinyin/ibus-libpinyin/issues/565that libbopomofo was for zh_TW locale users as
in https://github.com/libpinyin/ibus-libpinyin/issues/565#issuecomment-4667091412: > I guess libbopomofo is designed for
the zh_TW locale.
You could argue that libbopomofo is useless given that ibus-libzhuyin and ibus-chewing exists, but at least libbopomofo
is not for zh_CN users with this upstream statement.
After it migrates to Testing and gets builds with Debian Live systems, it would
be great
if you could work with relevant users to confirm whether (1) ibus-libbopomofo
is not
enabled by default in zh_TW locales, especially in Live systems, and (2)
simplified characters
are not emitted by default even if ibus-libbopomofo is selected in zh_TW
locales. If there
are behaviors that misses expectations, please feel free to let me know.
Second, I tested lower rank as same as in the new patch in VM before
the NMU. Simply lowering the priority rank does not prevent
libbopomofo from being enabled by default in iBus. Because it is still
enabled by default, the initialization bugs across the different
desktop environments still occur.
It would be great if you could also test the upstream-provided patch of
https://github.com/libpinyin/ibus-libpinyin/commit/c92478b3f5c65a2feae45b6bd24c292c8f059989
,
which is included as part of the ibus-libpinyin/1.16.5-3 upload.
Since modifying the engine's output does not resolve the default
enablement issue, could we consider a different approach? If we want
to keep the language mapping as it is, perhaps we could split
libbopomofo into its own separate binary package. This way, ensure it
will not be installed automatically by tasksel or included in the
Debian Live images, preventing the original issue while still allowing
users to install it manually if needed.
Splitting the package could be the most elegant solution. I will look into the
possibility,
through I doubt the feasibility as its integration with libpinyin is pretty
tight. I will
make some updates later.
Best,
Boyuan
Boyuan Yang <[email protected]>於 2026年6月7日週日，23:46寫道：
Hi Andrew,
在 2026/6/4 03:56, Andrew Lee 写道:
> Hi Boyuan,
>
> I just did a quick grep and found it's been configured as default for
> zh_TW locale in `src/default.inputmethod.xml.in.in
<http://default.inputmethod.xml.in.in>`. Accroding to git
> history on salsa. It's been introduced since version 1.16.1. So that
> Trixie was not affected.
>
> I will do a quick test locally and then do a NMU then.
Thanks for your prompt action. I just did a quick glance on the changes,
but the
patch does not look very reasonable to me. With a universal zh_TW -> zh_CN
replacement,
the patch makes libbopomofo an input method for zh_CN language, which you
know better
than me that this is not true. Plus this was not a regression introduced
after Trixie: if you look at
https://github.com/libpinyin/ibus-libpinyin/commit/cfdc88bb7c194d7b22dfefdf13f15c9f57e12836
,
the same lines exist in the pre-Trixie era source code.
I guess the proper fix would be finding out why libbopomofo was activated
as the
default in the Live image, and more importantly: which input method do you
consider
shall be the default one for people using zh_TW locale + Live environment.
I guess that should be ibus-chewing, is that true?
I have the following ideas in my mind:
(1) Lower the XML <rank> for libbopomofo, or raise the rank for
ibus-chewing. If IBus
engine supports a rank value higher than 100, I prefer the latter case.
(2) Split ibus-libpinyin and ibus-libzhuyin, so that libbopomofo is not
installed
by default by tasksel or the Live image.
Andrew: please confirm the input method preference with me, and then we
can proceed to
find a proper solution without hacky modification.
For Osamu-san: thank you for the hints, yet I am unsure about the
applicability to
the Live environment. The Live system always want to install all packages
(which could
be both good and bad). Yet people don't care about the implementation
details; they
just care the out-of-box Live experience under a given locale. Since the
current bug report
is only under the IBus world with specific locale (zh_TW), it might be
reasonable if we
limit the fix under a certain scope as well.
My current dissection on the issue is as follows:
(1) The previous round of communication has switched task-chinese-s-*
from using
fcitx5 to using ibus [1]. I was not in favor of this idea, but anyway it
landed in tasksel 3.87.
(2) Due to switch, ibus-libpinyin was newly introduced into the Live
system.
(3) The ibus-libpinyin implementation provides both libpinyin and
libbopomofo
input methods, with the former for zh_CN locale and the latter for zh_TW
locale.
(4) Due to hardcoded <rank> values in ibus-libpinyin upstream as well
as in ibus-chewing
upstream, libbopomofo has a higher rank value (98) [2] compared to
ibus-chewing (80) [3].
(5) In newly built Live images, the newly-introduced libbopomofo has
a higher rank
(aka priority) than ibus-chewing, due to which it gets enabled in the
zh_TW locale.
This change appears as a regression to the majority of zh_TW Live system
users.
I would describe this issue as yet another problem caused by the Live
system
implementation but here we are already.
Best,
Boyuan Yang
[1] https://salsa.debian.org/installer-team/tasksel/-/merge_requests/56
[2]
https://github.com/libpinyin/ibus-libpinyin/blob/4e18faacb58232696f9ceca5dcb8fff7e31cb766/src/default.inputmethod.xml.in.in#L37
[3]
https://github.com/chewing/ibus-chewing/blob/42689dcd7634756b6b5f0ec57e234401cbb567ae/data/chewing.xml.in#L24
> On Wed, Jun 3, 2026 at 1:53 PM Boyuan Yang <[email protected]> wrote:
>> Hi,
>>
>> 在 2026/6/3 4:59, Andrew Lee (李健秋) 写道:
>>> Source: ibus-libpinyin
>>> Version: 1.15.8-2
>>> Severity: grave
>>> X-Debbugs-Cc: [email protected], [email protected],
>>>
>>> Dear Maintainer,
>>>
>>> I am filing this with 'grave' severity because this configuration
completely
>>> breaks basic text input capability for native users in zh_TW locale,
>>> results the default desktop interface from Debian Live unusable.
>>>
>>> We found this issue in the live image which pulls all the locales
stuff.
>>> When user enter zh_TW (Taiwan) locale, the system enables
ibus-libpinyin
>>> by default as the primary Zhuyin/Bopomofo input method.
>>>
>>> We understand that the Debian Live images are designed to support all
>>> languages out of the box, which is why a wide variety of input methods
(such
>>> as Anthy/Mozc for Japanese and Hangul for Korean) are installed by
default.
>>> However, Debian Live handles them correctly: none of the Korean or
Japanese
>>> input methods are automatically enabled or forced onto other unrelated
>>> locales by default.
>>>
>>> Delivering localized desktop environment where the basic text input
fails
>>> to respect the chosen locale severely damages Debian's image among the
>>> community. It gives the impression that the operating system is
unrespected,
>>> poorly localized, and unaware of critical language differences, keep
users
>>> away right from the start.
>>>
>>> Please adjust the ibus-libpinyin package's default to not to enable by
>>> default for any locale other than zh_CN to make the localized desktop
in
>>> Debian Live accurate, respectful, and user-friendly.
>> Thanks for the info. As the Debian packaged version did not carry any
custom
>> patch, I guess this is a behavior from the original ibus-libpinyin
source
>> code. The package was provided unchanged in the past, and we may have to
>> patch it downstream in Debian to disable any unwanted behavior.
>>
>> Do you have any patch in your mind that you may consider appropriate?
>> Otherwise please consider also opening an issue at the upstream issue
>> tracker for some coordination with upstream. Just to let you know that
>> I personally am current still in Debian vacation so I won't have time
>> to dig into it, and help from other people would be welcome. NMU fixes
>> would be possible, and I can review the changeset when I have more time.
>> Feel free to let me know your thoughts.
>>
>> Best,
>> Boyuan
>
>
