[seunghan91]

Refs #293.

What changed and why

Korean users can read Korean in the guest since #188, but they cannot type it:
the factory image has no Hangul engine. This adds fcitx5-hangul and the
Korean counterparts of the zh-TW pieces from #188 — ko_KR.UTF-8, a KR glyph
preference, and Mac-language detection. Every new image gets the package, locale, font rules
and the extra group; a Mac that is not set to Korean keeps today's locale
mapping and starts in the Default group as before.

#293 offered two scopes. This is the fuller one, adapted to main: the
start-menu Language row it mentioned no longer exists, so Korean follows the
Mac's primary language the same way Traditional and Simplified Chinese already
do.

What changes

Concern	Change
Packages	Add fcitx5-hangul (pulls libhangul)
Locale	Generate ko_KR.UTF-8 alongside the existing three in configure-rootfs.sh; allow it in try-omarchy-locale and run-qemu-gpu.sh
Glyph variants	30-try-omarchy.conf prefers Noto Sans/Serif/Mono CJK KR for ko; the TC rules are untouched
Input method	A second fcitx5 group, Korean (keyboard-us, hangul). The Default group (US + Chewing) is unchanged
Language detection	A Mac whose primary language is ko maps to ko_KR.UTF-8 (LanguagePreferences.swift)
First owner account	When the locale is ko_KR.UTF-8, try-omarchy-locale moves Korean first in /etc/skel/.config/fcitx5/profile, so the owner account starts in the Korean group and Ctrl + Space toggles US ↔ Hangul

Why a separate group

A tap of Ctrl + Space toggles between the group's first item and the last
used input method; reaching a third item means holding Ctrl and cycling with
Space. With Hangul as a third item in Default (US, Chewing, Hangul), Chinese
and Korean users would share that cycle. A separate group leaves Default's
items unchanged and gives Korean users a predictable US ↔ Hangul toggle. fcitx5-remote -g Korean / -g Default switches groups by
hand, and fcitx5 saves the choice.

The reorder only runs when the profile's GroupOrder is still exactly the
factory's 0=Default / 1=Korean, and each file is replaced atomically. A
profile that is a symlink or any other non-regular file is refused before
either file is written, and the pending marker stays, so the next boot
retries. The unit already runs
Before=omarchy-provision-owner.service, which is what copies /etc/skel.

Compatibility

The new image advertises tryomarchy.locale_support=3. A disk with =2 has no
ko_KR locale and no Korean group, so for a Korean Mac the launcher sends
tryomarchy.locale=en_US.UTF-8 to such a disk instead, which is today's
behavior. =1 and older disks are handled as before. Existing VMs keep their
packages and profile; README says these defaults apply to new or reset guests.

Deliberately excluded

• The Mac Ctrl + Space conflict. macOS uses it for "Select the previous
  input source", so the key can be taken before it reaches the guest. Changing
  the trigger (e.g. to Caps Lock) touches Omarchy's compose:caps; I kept the
  defaults and put the options in a comment on Korean input: ship fcitx5-hangul (and optionally a Korean language option) #293 instead.
• Translating Omarchy's own interface — unchanged from [feat] Restore upstream's CJK font and fcitx5, add Traditional Chinese #188; README already
  says the setup wizard and menus stay in English.

Package lock

This is the part I could not do the way #188 did. The lock here is the
committed lock plus three hand-merged entries — fcitx5-hangul 5.1.11-1,
libhangul 0.2.0-1 and the new requestedFileSha256 — not a fresh resolve.

A real --refresh-package-lock against current ALARM moves 30 existing pins,
including hyprland 0.56.2-3 → -4. spec.json and
register-patched-hyprland.sh expect -3, so make guest stops at
register-patched-hyprland: unexpected upstream Hyprland package version.
After adjusting those to -4 in a scratch tree, it then fails with
target not found: cmake=4.4.3-2 and meson=1.12.1-1, the pinned build
dependencies of the patched Hyprland. main itself does not build today
either (#280), and #285 looks like the real fix, so I kept this PR's lock
change minimal rather than folding a Hyprland bump into it. Happy to rerun the
refresh once #280/#285 settle.

Testing

Tests — make test passes on this branch: 425 Swift tests, the guest
suite (373 Python tests, 1 skipped) and the native guest contract.
test_locale.py has 16 cases, including Korean GroupOrder reordering only from
the factory order, customized orders left alone, symlinked or non-regular
profiles refused with locale.conf untouched and the pending marker kept, a missing profile not recreated,
and idempotency. verify.py checks the expected Korean group and item lines, no
Items/2 in either group, the factory GroupOrder at the end, and the KR font
rules.
run-qemu-ssh-contract.test.sh covers the Korean hint against no capability,
=2 (falls back to en_US.UTF-8) and =3 (passed through).

Fonts — on a running guest, with this branch's 30-try-omarchy.conf
swapped into a copy of /etc/fonts, fc-match resolves lang=ko to
Noto Sans CJK KR / Noto Serif CJK KR / Noto Sans Mono CJK KR for
sans-serif / serif / monospace (today: Liberation Sans / Liberation Serif /
JetBrainsMono Nerd Font). en, zh-cn and zh-tw resolve exactly as they do
today.

Image — not built, for the reason above.

Input, on a running guest — on an existing guest with
fcitx5 5.1.23-1 and fcitx5-hangul 5.1.11-1 installed, in an isolated
/tmp home:

1. Ran this branch's try-omarchy-locale with
   tryomarchy.locale=ko_KR.UTF-8 against this branch's profile fragment:
   rc 0, LANG=ko_KR.UTF-8, GroupOrder became 0=Korean / 1=Default,
   marker consumed.
2. Started fcitx5 on that profile: current group Korean, input method
   keyboard-us.
3. Through fcitx5's DBus input-context frontend (the path the GTK/Qt modules
   use): gksrmf passed through as plain US input; Ctrl + Space switched to
   hangul, and gksrmf committed 한글; Ctrl + Space again returned to
   keyboard-us.

I could not run a second Hyprland session for this, so the Wayland
input-method path inside Hyprland is not covered by the above; it is the same
fcitx5 instance and engine that Chewing already uses there.

Drafted with help from Claude (an Anthropic AI model).

---

🤖 Generated with Claude Code