Hi Boyuan, Thank you for clarify the upstream intention and share the link to discussion.
On Thu, Jun 18, 2026 at 5:04 PM Boyuan Yang <[email protected]> wrote: > 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. The upstream commit appears to be focuing Traditional Chinese output. > 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. However, because Simplified Chinese and Tradiaitonal Chinese do not have an one-to-one mapping. Traditional Chinese contains a much larger pool of character set than Simplified Chinese. Even though libpinyin uses opencc for conversion, such converter does not provide the full character set natively required by zh_TW locale users. So that during my tests. I only found it was useful to type Simplified Chinese properly under zh_CN locale. And this useful case also gone with the new patch. > 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 this is technical limitation means the engine cannot fit the needs of zh_TW users regardless of how to forcing the output. Test the patch won't change the original issue. > 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. I checked the source code as well, and you are right about the tight integration. And during my tests, only spliting the XML files will gets an error every time when ibus is loaded. So that only split the xml file without a major upstream rewrite would probably impossible. However, if splitting the package turns out to be not possible, please consider reverting to the patch I provided in the NMU as the final solution with your lower rank patch. The NMU version successfully resolved the original issue, and also providing a working behavior for users under the zh_CN locale. I look forward to your updates on the package! 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
