Keyboard layouts and locale on Omarchy 4

Checked against Omarchy v4.0.4 (2026-09-16).

Omarchy 4 has one source of truth for your keyboard layout, and it is not a file in your home directory. It is /etc/vconsole.conf. Everything else reads from there, or deliberately ignores it. Once you know that, the rest of this page is detail.

Where the layout comes from on Omarchy 4

Setup asks you one keyboard question. The list of choices lives in install/provisioning/setup-form.sh as label and console keymap pairs, around fifty entries, defaulting to “English (US)”. Your answer goes through systemd-firstboot --keymap=, falling back to localectl set-keymap, so it lands as both the console KEYMAP and the XKB layout in /etc/vconsole.conf.

Then Omarchy’s packaged /usr/share/omarchy/default/hypr/input.lua opens that file at every Hyprland start and reads XKBLAYOUT and XKBVARIANT out of it, falling back to us. No per-user rewrite happens.

This is new in 4.0.0. On 3.x, install/config/detect-keyboard-layout.sh ran once at install time and used sed to splice a kb_layout line into your ~/.config/hypr/input.conf. After that the two files could drift apart forever. If you upgraded from 3.x, migration 1781485962.sh replaced your input.lua with the packaged one, but only if the file was otherwise stock and any kb_layout or kb_variant it carried matched vconsole.conf. Then the live read took over. If you had customized anything else in it, your file was left alone and your old hardcoded layout still wins.

The packaged defaults you inherit are repeat_rate = 40, repeat_delay = 250, numlock_by_default = true, and kb_options = "compose:caps,shift:both_capslock_cancel". Caps Lock is the compose key, and both Shift keys together give you Caps Lock back, self-cancelling on the next lone Shift.

Change the layout for the whole machine

This is the right route if you want the TTY, the LUKS prompt and Hyprland to agree.

sudo localectl set-keymap de
sudo localectl set-x11-keymap de pc105 nodeadkeys
cat /etc/vconsole.conf
hyprctl reload

If your disk is encrypted, the unlock prompt only picks this up after the initramfs is rebuilt:

sudo limine-mkinitcpio

Check it landed with hyprctl devices, which lists every keyboard on the seat with its active keymap.

Override it per user in input.lua

~/.config/hypr/input.lua is loaded after Omarchy’s defaults, and anything you uncomment there replaces them. You can also reach it from Setup > Input in the Omarchy menu (Super + Space). Hyprland auto-reloads on save.

hl.config({
  input = {
    kb_layout = "us,de",
    kb_variant = ",nodeadkeys",
    kb_options = "compose:caps,shift:both_capslock_cancel,grp:alts_toggle",
  },
})

One trap worth spelling out. kb_options is a replacement, not an addition. If you set it to just grp:alts_toggle you silently lose the compose key and the Shift handling, and your CapsLock emoji and completion sequences stop working. Carry compose:caps,shift:both_capslock_cancel forward every time. The manual’s own examples do this, which is why they all look repetitive.

kb_variant is positional against kb_layout. Two layouts need two comma-separated variant slots, even when the first one is empty.

Switching between layouts

With two or more layouts configured, grp:alts_toggle cycles them on Left Alt plus Right Alt. That is the option the manual and the FAQ both use.

The bar also carries a keyboard layout widget, omarchy.keyboard-layout, added to the default layout by migration 1786279107.sh and placed just right of the clock. It only renders when the active keyboard has more than one layout, so on a single-layout machine there is nothing to see. Clicking it runs hyprctl switchxkblayout <keyboard> next on the keyboard the widget is describing. If yours is missing:

omarchy bar put omarchy.keyboard-layout --after omarchy.clock

The LUKS trap on non-Latin layouts

Bundling /etc/vconsole.conf into the initramfs is what makes Plymouth apply your layout at the LUKS prompt. For a Hebrew, Greek, Cyrillic, Arabic or similar layout that backfires badly: the passphrase is Latin, the prompt is not, and you cannot type it. elpddev reported exactly that lockout in issue #6229, with only older snapshot boot entries still unlocking.

Omarchy 4 handles this in two places. etc/mkinitcpio.conf.d/omarchy_hooks.conf only adds FILES+=(/etc/vconsole.conf) when the first layout is not in the non-Latin list, and migration 1784476564.sh strips the line and rebuilds the UKI on machines that already had it. The list covers af am ara bd bg by et ge gr il in iq ir kg kh kz la lk mk mm mn mv np rs ru sy th tj ua.

So on a non-Latin layout the unlock prompt stays US QWERTY by design. Type the passphrase as if you were on a US keyboard. The guard is not in v3.8.4, which still bundles unconditionally via migration 1783355853.sh.

The same list appears a second time in default/hypr/input.lua, for a different reason. Hyprland matches keybindings against whichever layout is listed first in kb_layout, regardless of which one you are typing on, so a non-Latin layout in front would break SUPER + W and everything like it. Omarchy prepends us, and appends grp:alts_toggle so your real layout is one Alt-Alt away.

Why the clock and calendar are English

This is settled, not broken. The clock plugin formats its dates with Qt.formatDateTime and Qt.formatDate, and those two calls take their weekday names, month names and AM/PM markers from the C locale. Qt.locale() can report sv_SE all it likes; the Quickshell bar clock still comes out English.

isaac30503 reported it as issue #6934 and diagnosed it correctly. DHH closed it as not planned on the same day. His reasoning: menus, panels and notifications are all English, so a translated clock would not make the desktop consistent, it would just be the single translated thing on it. The calendar popup, which had been reading day names from the system locale, was treated as the accident. PR #6988 by DHH, merged 2026-08-15, made the calendar’s day names English too by pinning labelLocale to Qt.locale("en_US") in shell/plugins/panels/clock/Panel.qml. The first day of the week was left alone because it is a regional setting rather than a piece of text, and you can still set it yourself with weekStartDay.

Issues #7211, #7760 and #8600 all report the same surface from different angles and are all still open on 4.0.4. Treat English dates as current behaviour, not as a bug waiting on you.

There is also no language question at setup. Nothing in the omarchy repository writes /etc/locale.gen or /etc/locale.conf. Setup asks for keyboard layout, your account details, hostname and timezone, and that is all.

Input methods: what is already installed

install/omarchy-base.packages on 4.0.4 ships fcitx5, fcitx5-gtk, fcitx5-qt, plus noto-fonts, noto-fonts-cjk and noto-fonts-emoji. fcitx5 runs as omarchy-fcitx5.service under systemd, supervised since migration 1785167800.sh, because it is what powers the CapsLock compose sequences.

So the framework and the CJK fonts are already there on a stock install. What is not there is an engine, and fcitx5-configtool is not in the base package list either. It appears in the retired-package list inside omarchy-upgrade-to-quattro, so a 3.x machine that had it loses it on the upgrade. Install what you need:

omarchy pkg add fcitx5-configtool fcitx5-mozc
omarchy restart xcompose

Then use fcitx5-configtool to add the engine to your input method group and set the switch key. Per-language walkthroughs live at Chinese input with fcitx5, Japanese input with Mozc and Korean Hangul input.

What to watch for on newer versions

Five relevant pull requests were open against omacom/omarchy on 2026-09-16. None of them is merged, so nothing here describes current behaviour.

PR	Author	What it proposes
#9695	ZacharyZhang-NY	A Setup > Region toggle between World and China that switches the system language to zh_CN, installs a Rime input method and swaps the menu to Chinese labels
#9634	komagata	A Setup > Input Method > Mozc (Japanese) menu entry that installs fcitx5-mozc and appends Mozc to the current input method group
#9299	ronaldlangeveld	Korean as an install-time keyboard choice, wired through fcitx5 rather than a console keymap, since kbd ships none for Korean
#10949	sbelcl	A language question at setup plus an omarchy-menu-language entry, so LANG is not left at the default
#10955	sbelcl	Replacing Qt.formatDateTime with toLocaleString(Qt.locale(), ...) so day and month names follow the system locale

The last one is worth watching closely, because it points the opposite way from the decision in #6934. If it merges, English dates stop being the answer. Until then they are.

DHH has said on X that the next release will be called “Quattro RS 4.5” rather than 4.1. I found nothing published about it that commits to any of these five, so do not plan around them.

Related

• Hyprland conf to Lua migration
• Non-US keyboard layout at LUKS and SDDM
• Upgrading 3 to 4