Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Bar clock always shows weekday/month names in English, ignoring system locale (LANG)
Reported by isaac30503 · filed Aug 15, 2026Closed upstream on 2026-08-15 by dhh, as not planned.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Title
Bar clock always shows weekday/month names in English, ignoring system locale (LANG)
Description
The bar clock widget (omarchy.clock) always renders weekday names (dddd/ddd) and month names (MMMM/MMM) in English, regardless of the system locale. Setting LANG/LC_TIME to a non-English locale (e.g. es_MX.UTF-8) correctly changes every other locale-aware value on the system, but the clock widget in the bar is unaffected.
This used to work correctly under the old waybar-based bar (pre-Quattro); it broke after the migration to the Quickshell-based omarchy-shell.
Steps to reproduce
- Set a non-English system locale, e.g.:
localectl set-locale LANG=es_MX.UTF-8 and reboot.
2. Confirm the locale is applied system-wide:
$ localectl status
System Locale: LANG=es_MX.UTF-8
$ systemctl --user show-environment | grep LANG
LANG=es_MX.UTF-8- Set the bar clock format to include a weekday/month token, e.g.
dddd HH:mm(the default). - Observe the bar: it shows
Saturday 14:05instead of the expectedsábado 14:05.
Root cause
BarWidget.qml for the clock plugin formats the date with the QML global function Qt.formatDateTime(date, format):
https://github.com/basecamp/omarchy/blob/master/shell/plugins/panels/clock/BarWidget.qml
function formatted(date) {
return Qt.formatDateTime(date, activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}The two-argument Qt.formatDateTime(date, format) overload does not use the application's default locale for textual tokens (dddd, ddd, MMMM, MMM) — it always formats those using English/C-locale names, independent of Qt.locale() or the process environment.
I confirmed this directly against the running quickshell binary (Quickshell 0.3.0) with LANG=es_MX.UTF-8 LC_ALL=es_MX.UTF-8:
Qt.locale().name: es_MX
Qt.formatDateTime(d, "dddd d MMMM"): Saturday 15 August ← wrong
d.toLocaleString(Qt.locale(), "dddd HH:mm"): sábado 14:05 ← correctSo Qt.locale() correctly resolves to es_MX (the system/env locale is picked up fine), but Qt.formatDateTime() simply doesn't consult it for weekday/month names. Date.prototype.toLocaleString(locale, format) (and toLocaleDateString/toLocaleTimeString), by contrast, do honor the passed-in QLocale and render the correct localized names, while still supporting the same format-token syntax (including the custom ww week-number substitution already done by Model.isoWeekLiteral).
Suggested fix
Swap the formatting call in formatted() to a locale-aware one:
function formatted(date) {
return date.toLocaleString(Qt.locale(), activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}I applied exactly this one-line change locally and confirmed the bar clock now renders correctly in Spanish (sáb 15 ago 01:47 instead of Sat 15 Aug 01:47) after an omarchy-restart-shell. No other format tokens (vertical format, 'W'ww week literal, AM/PM) regressed in my testing.
I didn't find any other use of Qt.formatDateTime elsewhere in shell/, so this appears to be the only spot affected.
Environment
- Omarchy: 4.0.0-1
- quickshell-git: 0.3.0.r20.g28771c7-1
- Hyprland: 0.56.2-1
- Locale:
LANG=es_MX.UTF-8
View raw text
## Title
Bar clock always shows weekday/month names in English, ignoring system locale (LANG)
## Description
The bar clock widget (`omarchy.clock`) always renders weekday names (`dddd`/`ddd`) and month names (`MMMM`/`MMM`) in English, regardless of the system locale. Setting `LANG`/`LC_TIME` to a non-English locale (e.g. `es_MX.UTF-8`) correctly changes every other locale-aware value on the system, but the clock widget in the bar is unaffected.
This used to work correctly under the old waybar-based bar (pre-Quattro); it broke after the migration to the Quickshell-based `omarchy-shell`.
## Steps to reproduce
1. Set a non-English system locale, e.g.:
```
localectl set-locale LANG=es_MX.UTF-8
```
and reboot.
2. Confirm the locale is applied system-wide:
```
$ localectl status
System Locale: LANG=es_MX.UTF-8
$ systemctl --user show-environment | grep LANG
LANG=es_MX.UTF-8
```
3. Set the bar clock format to include a weekday/month token, e.g. `dddd HH:mm` (the default).
4. Observe the bar: it shows `Saturday 14:05` instead of the expected `sábado 14:05`.
## Root cause
`BarWidget.qml` for the clock plugin formats the date with the QML global function `Qt.formatDateTime(date, format)`:
https://github.com/basecamp/omarchy/blob/master/shell/plugins/panels/clock/BarWidget.qml
```qml
function formatted(date) {
return Qt.formatDateTime(date, activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}
```
The two-argument `Qt.formatDateTime(date, format)` overload does **not** use the application's default locale for textual tokens (`dddd`, `ddd`, `MMMM`, `MMM`) — it always formats those using English/C-locale names, independent of `Qt.locale()` or the process environment.
I confirmed this directly against the running `quickshell` binary (`Quickshell 0.3.0`) with `LANG=es_MX.UTF-8 LC_ALL=es_MX.UTF-8`:
```
Qt.locale().name: es_MX
Qt.formatDateTime(d, "dddd d MMMM"): Saturday 15 August ← wrong
d.toLocaleString(Qt.locale(), "dddd HH:mm"): sábado 14:05 ← correct
```
So `Qt.locale()` correctly resolves to `es_MX` (the system/env locale is picked up fine), but `Qt.formatDateTime()` simply doesn't consult it for weekday/month names. `Date.prototype.toLocaleString(locale, format)` (and `toLocaleDateString`/`toLocaleTimeString`), by contrast, do honor the passed-in `QLocale` and render the correct localized names, while still supporting the same format-token syntax (including the custom `ww` week-number substitution already done by `Model.isoWeekLiteral`).
## Suggested fix
Swap the formatting call in `formatted()` to a locale-aware one:
```qml
function formatted(date) {
return date.toLocaleString(Qt.locale(), activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}
```
I applied exactly this one-line change locally and confirmed the bar clock now renders correctly in Spanish (`sáb 15 ago 01:47` instead of `Sat 15 Aug 01:47`) after an `omarchy-restart-shell`. No other format tokens (vertical format, `'W'ww` week literal, AM/PM) regressed in my testing.
I didn't find any other use of `Qt.formatDateTime` elsewhere in `shell/`, so this appears to be the only spot affected.
## Environment
- Omarchy: 4.0.0-1
- quickshell-git: 0.3.0.r20.g28771c7-1
- Hyprland: 0.56.2-1
- Locale: `LANG=es_MX.UTF-8`
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
- Fixed bypr/7173· confirmed
- Related PRpr/10776· confirmed
- Related PRpr/13546· confirmed
- Fixed bypr/13851· confirmed
- Related PRpr/15117· 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.
No decision has been recorded yet.