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. Best regards, -Andrew 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`. 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 > > > > > >
