zh-TW support: restore upstream's fcitx5 and Noto CJK, add Traditional Chinese locale and Bopomofo input

[k5953837]

🤖 This issue was written by Claude Opus 5 (an Anthropic AI model) on behalf of @k5953837, who asked it to add Traditional Chinese support and to read the project's contribution rules first. The upstream package list, the package sizes, and the mirror state below were read directly from the pinned Omarchy tree and the live Arch Linux ARM mirrors on 2026-09-09. The branch described under “Status and blocker” passes guest/test locally; the factory image itself has not been built, for the reason given there.

Summary

The factory guest cannot display or type Traditional Chinese today. It generates only en_US.UTF-8, ships no CJK font, and omits fcitx5, so Chinese text renders as tofu boxes and there is no way to enter it.

The part worth stating up front: upstream Omarchy already ships the pieces that make this work. At the pinned release (4.0.2, 346e69e1c), install/omarchy-base.packages contains:

35: fcitx5
36: fcitx5-gtk
37: fcitx5-qt
88: noto-fonts-cjk

guest/packages.txt — the intentionally trimmed ARM64 transaction — drops all four. So this is not a request to add something Omarchy lacks. It is a request to restore what the trim removed, plus the Traditional-Chinese-specific pieces upstream does not cover.

The trim has already cost one bug: #91, where the omitted fcitx5 binary left upstream's omarchy-fcitx5.service in a 203/EXEC restart loop that flooded the journal. #106 fixed that defensively with a ConditionPathExists=/usr/bin/fcitx5 drop-in — a guard that is self-healing, so installing the package makes it pass with no change to the guard.

Why this belongs here rather than upstream

Two earlier pull requests proposed Simplified Chinese support (#26, #63). Both were withdrawn by their own authors, and #26's closing comment argued the work "belongs in upstream Omarchy... not the Try Omarchy wrapper."

The package list above is the reason I think that reasoning does not hold. Upstream has already made the call to ship fcitx5 and Noto CJK. The gap exists only inside this fork's ARM64 trim, so it can only be closed here. What upstream does not provide, and what is genuinely this project's to decide, is the zh-TW-specific configuration: a Traditional Chinese locale, a font rule that picks TC Han glyph variants over Simplified or Japanese ones, and a Bopomofo engine.

Proposed change

Concern	Change
Locale	Generate zh_TW.UTF-8 alongside en_US.UTF-8 in configure-rootfs.sh. LANG stays en_US.UTF-8 and KEYMAP stays us — the locale becomes available, not default.
Fonts	Restore upstream's noto-fonts-cjk.
Glyph variants	New etc/fonts/conf.d/30-*.conf preferring Noto Sans/Serif/Mono CJK TC when the text language is zh-tw or zh-hant. Without it, shared codepoints render with Simplified or Japanese forms.
Input method	Restore upstream's fcitx5, fcitx5-gtk, fcitx5-qt; add fcitx5-chewing for Bopomofo.
Input method defaults	Seed /etc/skel/.config/fcitx5/profile with keyboard-us as the first item and chewing as the second, so a user who never presses Ctrl+Space sees no change at all.
XWayland	XMODIFIERS=@im=fcitx in environment.d. GTK_IM_MODULE/QT_IM_MODULE are deliberately left unset so native Wayland GTK4/Qt6 apps keep using text-input-v3, which Hyprland implements.
Chromium	Append --enable-wayland-ime to upstream's /etc/skel/.config/chromium-flags.conf. Chromium on Wayland ignores input methods without it, and Chromium is the browser this image ships.

Net effect for an existing English-speaking user: none. The default session language, keyboard layout, and first input method are unchanged.

Deliberately excluded

• fcitx5-chinese-addons — hard-depends on qt6-webengine, which does not fit the 6144 MiB factory image. Add Chinese input and locale to the factory guest #63 hit the same wall. Bopomofo via fcitx5-chewing does not need it.
• fcitx5-configtool — upstream does not ship it either, and it pulls a KDE dependency chain (kwidgetsaddons alone is ~15 MiB). Excluded to keep the package set identical to upstream's plus one engine.
• Raising image.sizeMiB — that value is duplicated as a runtime contract in macos/run-qemu-gpu.sh and asserted in macos/Tests/run-qemu-ssh-contract.test.sh, so changing it is an architecture discussion, not part of this.
• Localising the macOS launcher UI — unrelated to the guest and a separate proposal.
• Changing the default language — see above.

Size

Measured Installed Size from pacman -Si in an aarch64 builder container:

Package	Installed Size
noto-fonts-cjk	298.79 MiB
fcitx5	20.72 MiB
fcitx5-qt	2.28 MiB
fcitx5-gtk	516 KiB
fcitx5-chewing	171 KiB

Plus new transitive dependencies, of which libchewing (6.78 MiB) is the largest; the exact set is pending the lock refresh below.

guest/scripts/pack-image.sh requires the staged root to stay under 85% of 6144 MiB. I have not been able to measure the actual headroom yet, for the reason below. If it turns out to be tight, adobe-source-han-sans-tw-fonts (38.15 MiB, Traditional Chinese only) is a fallback, at the cost of dropping Japanese and Korean coverage that upstream currently provides.

Status and blocker

The non-package half of this is implemented and passing guest/test on a branch here: locale generation, the fcitx5 profile fragment, the Chromium flag append, the fontconfig rule, the XMODIFIERS entry, and ten new assertions in guest/tests/verify.py covering the contract — including one that the default LANG/KEYMAP stay English.

I cannot complete it yet: adding packages requires regenerating guest/packages.lock.json, and that is blocked by the two upstream drifts in #171 (the builder's rust pin no longer exists on the ALARM mirror, and no single aquamarine currently satisfies both hyprland and hyprtoolkit). I am waiting on that rather than working around it, since CONTRIBUTING.md asks that pinned inputs not be changed independently of their validation code.

Question

Before I open a pull request: is Traditional Chinese support something you want in Try Omarchy? Given that the packages come straight back from upstream's own list and the default English experience is untouched, I think the surface area is small — but #26 and #63 suggest previous contributors were unsure of your position, and I would rather ask than guess.

If you would prefer a narrower first step — for example restoring only noto-fonts-cjk so CJK text renders, and leaving input methods for later — I am happy to split it that way.

[k5953837]

🤖 Written by Claude Opus 5 on behalf of @k5953837. Everything below was measured on 2026-09-09; the commands and their output are quoted verbatim.

Update: I was able to answer the two open questions from the original post. Since main cannot build a guest today (#171), I stacked the zh-TW commits on top of #142 in a throwaway branch and built there. The numbers below therefore describe #142 + zh-TW, not main + zh-TW — but the package set and overlay files are the same ones I would open the PR with.

The lock refreshes cleanly

guest/build-container.sh --refresh-package-lock succeeded, which also settles that fcitx5-chewing exists for aarch64:

Packages	614 → 623
Added (9)	enchant, fcitx5, fcitx5-chewing, fcitx5-gtk, fcitx5-qt, libchewing, noto-fonts-cjk, xcb-imdkit, yoga
Removed	0
Version changes	1 — archlinux-keyring 20260902-1 → 20260909-1 (today's mirror bump, unrelated to this)
requestedFileSha256	matches packages.txt

Dropping fcitx5-configtool — which upstream does not ship either — is what keeps this at 9 rather than 14: it was pulling kdbusaddons, kitemviews, kwidgetsaddons (~15 MiB) and kwindowsystem.

The image fits, with room to spare

make guest completed in 55 minutes, EXIT=0:

Packed guest artifacts in /output
Guest build complete: /output/guest-manifest.json
omarchy-factory: 130881/393216 files (0.1% non-contiguous), 1297806/1572864 blocks

1,297,806 × 4 KiB = 5,068.5 MiB of 6,144 MiB, i.e. 82.5% — under pack-image.sh's 85% ceiling, and that figure counts ext4 metadata the du -sk check does not, so the staged root has more margin than 82.5% suggests.

So the adobe-source-han-sans-tw-fonts fallback I offered in the original post is not needed. noto-fonts-cjk fits, and keeping it preserves the Japanese and Korean coverage upstream already ships.

What actually landed in the image

Read back out of dist/guest/rootfs.ext4 with debugfs, rather than inferred from the scripts:

• /etc/locale.gen — en_US.UTF-8 UTF-8 and zh_TW.UTF-8 UTF-8
• /etc/locale.conf — LANG=en_US.UTF-8; /etc/vconsole.conf — KEYMAP=us (both unchanged)
• /usr/lib/locale/locale-archive — contains zh_TW.utf8, so locale-gen did compile it
• /etc/skel/.config/chromium-flags.conf — upstream's five flags intact, with --enable-wayland-ime appended
• /usr/lib/environment.d/90-try-omarchy.conf — XMODIFIERS=@im=fcitx, no GTK_IM_MODULE/QT_IM_MODULE assignment
• /usr/bin/fcitx5 — present, so the ConditionPathExists guard added in Guard omitted fcitx5 and bt-agent user units #106 now passes on its own
• /usr/share/fcitx5/inputmethod/chewing.conf — present, which is what makes Name=chewing in the seeded profile a registered input-method name rather than a typo

Font selection verified, not assumed

Running fc-match against the image's own .ttc files with the new conf.d rule loaded:

:lang=zh-tw:family=sans-serif   → Noto Sans CJK TC
:lang=zh-tw:family=serif        → Noto Serif CJK TC
:lang=zh-tw:family=monospace    → Noto Sans Mono CJK TC

zh-cn, ja and en are unaffected. fc-query confirms all three family names really exist in the shipped collections, so the rule cannot silently no-op on a renamed family.

Still outstanding

I have not booted the image and typed Chinese yet — that needs the QEMU runtime built locally. I will follow up with that before opening the PR.

And the PR itself still waits on #142, since packages.txt and packages.lock.json have to land together and main cannot regenerate the lock today.

[k5953837]

🤖 Written by Claude Opus 5 on behalf of @k5953837. Follow-up to the previous comment: the image has now been booted and Chinese typed in it.

Booted the image I built on top of #142, in ephemeral mode so nothing touched an existing VM, and ran through owner provisioning normally (Asia/Taipei, English (US) keyboard).

What the running guest reports

$ locale -a | grep -i zh_TW
zh_TW.utf8

$ echo "XMOD=$XMODIFIERS GTK_IM=${GTK_IM_MODULE:-unset} QT_IM=${QT_IM_MODULE:-unset}"
XMOD=@im=fcitx GTK_IM=unset QT_IM=fcitx

$ pgrep -a fcitx5
11039 /usr/bin/fcitx5 --disable notificationitem

$ fc-match -f "%{family}\n" :lang=zh-tw:family=sans-serif
Noto Sans CJK TC

Two things worth calling out:

fcitx5 started on its own. Nothing in this change enables a unit. The ConditionPathExists=/usr/bin/fcitx5 drop-in added in #106 simply stops being a blocker once the binary exists, and upstream's omarchy-fcitx5.service takes it from there. The guard needs no edit.

QT_IM_MODULE=fcitx is set, but not by this change. Our environment.d file deliberately sets only XMODIFIERS; that value arrives from elsewhere in the system. GTK_IM_MODULE stays unset, which is the part that matters for GTK4-on-Wayland.

Rendering

$ printf '繁體中文測試 骨戶直黃起\n'
繁體中文測試 骨戶直黃起

No tofu. Those five test characters are ones where Traditional and Simplified/Japanese glyph variants differ, and they render in the Traditional forms.

Bopomofo input

With the seeded profile, Ctrl+Space switches to Chewing, and the standard Bopomofo keys work:

$ echo 你好 from omarchy
你好 from omarchy

Typed as: Ctrl+Space → su3 (ㄋㄧˇ) → cl3 (ㄏㄠˇ) → Ctrl+Space back to English → from omarchy. Switching back leaves plain US input exactly as before, which is the property the item ordering in the seeded profile is there to guarantee.

Where this leaves the PR

Everything I claimed in the original post is now verified against a real boot rather than the image contents alone. The remaining dependency is unchanged: packages.txt and packages.lock.json have to land together, and main cannot regenerate the lock until #142 (or its successor) is in. I will open the PR against main once that is resolved.