Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-645GitHub issuePublicDecided· Out of scope

Feature request: out-of-the-box Chinese input support — is it on the roadmap?

Reported by jamesMuWB · filed Sep 12, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Feature request: out-of-the-box Chinese input support — is it on the roadmap?revision 1 · captured 2026-09-28 21:23 UTC via poll

Summary

Omarchy ships the fcitx5 framework by default (via omarchy-fcitx5.service), but typing Chinese currently requires manually installing an IME engine (e.g. fcitx5-chinese-addons for Pinyin) and wiring up the configuration by hand, as described in manual/34-keyboard-mouse-trackpad.md. For Chinese-speaking users this makes the initial experience noticeably short of the "just works" bar Omarchy sets everywhere else.

What I'd love to see

  • Chinese input working out of the box, or at least offered as an option in the first-run setup wizard (which already asks about language/keyboard preferences).
  • Optionally: preinstall fcitx5-chinese-addons (Pinyin) alongside the existing fcitx5 setup, with a sensible default toggle key that doesn't clash with existing bindings.

Related friction already reported

Even after manual setup, there are several open issues affecting Chinese users, which suggests the CJK path doesn't get exercised much by default:

  • #7440 — default shift:both_capslock_cancel kb option breaks fcitx5 Shift toggle
  • #7346 — modifier release events dropped with fcitx5-rime
  • #4842 — Ctrl+Space tmux prefix conflicts with the fcitx5 toggle
  • #7559 — Fcitx5 candidate window misplaced in native Wayland Chromium/Electron apps

Question

Is out-of-the-box CJK input support on the roadmap? If yes, is there a rough timeline or a preferred approach (first-run wizard vs. default preinstall) that community help could accelerate?

View raw text
## Summary

Omarchy ships the fcitx5 framework by default (via `omarchy-fcitx5.service`), but typing Chinese currently requires manually installing an IME engine (e.g. `fcitx5-chinese-addons` for Pinyin) and wiring up the configuration by hand, as described in `manual/34-keyboard-mouse-trackpad.md`. For Chinese-speaking users this makes the initial experience noticeably short of the "just works" bar Omarchy sets everywhere else.

## What I'd love to see

- Chinese input working out of the box, or at least offered as an option in the first-run setup wizard (which already asks about language/keyboard preferences).
- Optionally: preinstall `fcitx5-chinese-addons` (Pinyin) alongside the existing fcitx5 setup, with a sensible default toggle key that doesn't clash with existing bindings.

## Related friction already reported

Even after manual setup, there are several open issues affecting Chinese users, which suggests the CJK path doesn't get exercised much by default:

- #7440 — default `shift:both_capslock_cancel` kb option breaks fcitx5 Shift toggle
- #7346 — modifier release events dropped with fcitx5-rime
- #4842 — Ctrl+Space tmux prefix conflicts with the fcitx5 toggle
- #7559 — Fcitx5 candidate window misplaced in native Wayland Chromium/Electron apps

## Question

Is out-of-the-box CJK input support on the roadmap? If yes, is there a rough timeline or a preferred approach (first-run wizard vs. default preinstall) that community help could accelerate?

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

  • Related PRpr/13690· confirmed
  • Related PRpr/12312· confirmed
  • Related PRpr/9695· confirmed

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 12:12 UTC