Offer Korean as an install-time keyboard choice

[ronaldlangeveld]

Korean is missing from the install-time keyboard picker because it never fit the picker's model: the list maps labels to console keymaps, kbd ships no Korean console keymap, and Korean input isn't a keymap anyway — Korean keyboards type Latin on the US map, and Hangul comes from an input method. Since Omarchy already runs fcitx5 in every session (for the XCompose sequences), Korean turns out to be one package and a little wiring away.

What this does

Selecting Korean at install gives a machine that types English until the 한/영 key toggles Hangul, exactly the way Korean users expect. Caps Lock stays the compose key, like every other layout.

• setup-form.sh gains Korean|kr. There's no Korean console keymap, so apply_keyboard special-cases it: the console gets us, and XKBLAYOUT=kr is persisted in /etc/vconsole.conf. Hyprland's packaged input config already reads its layout from there, so kr flows through untouched (it's a Latin-typing layout, so no us,-prefix treatment).
• fcitx5-hangul joins the base packages next to the fcitx5 packages already shipped.
• A new first-run leaf, install/user/first-run/korean-ime.sh, seeds ~/.config/fcitx5/{profile,config} for the new user when the machine's XKBLAYOUT is kr: hangul engine in the input methods, Hangul + Control+space as trigger keys, English active by default.
• The 한/영 key needs no per-keyboard handling: xkb maps <HNGL> to the Hangul keysym globally (symbols/pc), so it works on any layout on standard Korean keyboards. Control+space covers keyboards without a dedicated key.

The seeding is deliberate about the fact that fcitx5 owns those two files. fcitx5 writes a default profile the moment it starts, and Hyprland's autostart runs first-run well after graphical-session.target has started it — so the files always exist by then and their presence proves nothing. The leaf tests for the hangul engine instead, and stops fcitx5 across the write, because its save-on-exit would otherwise put the default group straight back over the seed. An account that already lists hangul is left alone, so a user's own fcitx5 setup survives a forced first-run rerun.

The first commit is a standalone fix this feature surfaced: Chromium browsers on native Wayland ignore the compositor's text-input protocol unless launched with --enable-wayland-ime, which leaves fcitx5 dead in every browser text field — that already breaks the shipped XCompose emoji/expansion sequences today, not just Korean. The flags are added to config/chromium-flags.conf.

Testing

Verified end to end on a locally built ISO (omarchy-iso-make --local-source) in a QEMU VM: selected Korean in the installer, and the installed machine came up with KEYMAP=us / XKBLAYOUT=kr, a seeded fcitx5 profile, and Ctrl+Space switching straight into Hangul with no manual setup.

Unit coverage:

• setup-form-test.sh: Korean resolves to the kr marker.
• hyprland-keyboard-layout-test.sh: XKBLAYOUT=kr passes through Latin-led.
• The first-run leaf was exercised across its paths: seeds over the default profile fcitx5 creates for itself, unchanged on rerun, preserves an account that already has hangul, and no-ops on non-Korean machines.

Companion change

The ISO configurator sources the same setup-form.sh, so it picks up the new entry, but configure_keyboard in omarchy-iso rejects any keymap localectl doesn't know — which silently drops Korean back to the default layout and leaves no marker for the first-run leaf. That repo also has a test asserting every configurator keymap is a known keymap, which this PR would otherwise break.

The matching change is ready and is what the ISO above was built with: resolve such layouts to a Latin console keymap for KEYMAP, then point XKBLAYOUT back at the chosen layout. Happy to open it as soon as this direction looks right.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RGyJjcWvARsM1szQ9Uq9bp

[ronaldlangeveld]