Hi Andrew, 在 2026/6/7 18:11, Andrew Lee 写道:
Hi Boyuan,I think it’s appropriate as libbopomofo is for typing simplified chinese characters which isn’t suitable for zh_TW locale but zh_CN locale. Adjust the <rank> won’t be necessary.I forgot to also mention that everything I type via libbopomofo gives me simplified chinese characters even under zh_TW locale when I found the issue in Debian live image.And after the patch. I tested that it won’t be enabled by default in zh_TW locale but in zh_CN locale which helps users may type proper simplified characters under zh_CN locale with libbopomofo.
Many thanks for the follow-up information. At this moment, it looks more like an upstream bug to me: libbopomofo either (1) wrongly declared itself suitable for zh_TW locale while correctly emitting simplified characters, or (2) wrongly priotorised simplified characters while declaring itself suitable for zh_TW locale. I have opened an upstream bug report at https://github.com/libpinyin/ibus-libpinyin/issues/565 to see what the upstream author says. 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 > >
OpenPGP_0xC293E7B461825ACE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
