Hi, Holger Wansing <[email protected]> (2026-07-08): > So I'm tagging this bug wontfix. > > Thanks for confirmation!
Yes, it's great to have a confirmed workaround, and yes, that's a tricky
situation, as we're running into some kind of conflict… For the record,
we start with language set to zh_TW:zh (and zh_TW.UTF-8 as default
locale) after picking Chinese (Traditional), which get replaced with
zh_CN:zh_TW:zh (and zh_CN.UTF-8) after picking the default entry (3rd
from the top).
I'm wondering whether it would make sense to special case this, making
sure to keep zh_TW:zh (and zh_TW.UTF-8)… After all, if someone wanted
zh_CN (and zh_CN.UTF-8), why would they pick Chinese (Traditional) in
the first place?
Alternatively, we could try and detect this weird situation and adjust
the supported locale priority to make sure one has a chance to either
add zh_TW.UTF-8 to zh_CN.UTF-8 or replace the latter entirely, but that
wouldn't change the fact zh_CN would be used instead of zh_TW for the
entirety of the installer's runtime?
Just in case someone wants to play around, here's a reminder of which
country is which:
Template: localechooser/shortlist/zh_TW
Type: select
Choices-C: CN, SG, TW, HK, other
Choices: China, Singapore, Taiwan, Hong Kong, other
Choices-zh_TW.UTF-8: 中國, 新加坡, 臺灣, 香港, 其它
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
