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. > 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. 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. 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 > >> <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 > >> > > >> > > >> > > > -- -Andrew
