Fix shortcut recorder app-language mismatch - #3190
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
Codex review: needs real behavior proof before merge. Reviewed August 25, 2026, 9:26 AM ET / 13:26 UTC. ClawSweeper reviewWhat this changesThe PR makes the menu-shortcut recorder’s idle and recording prompts follow CodexBar’s selected in-app language, with 23 locale updates and focused coverage. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 3 items remain Keep open: this is a narrow, source-aligned fix with no blocking correctness defect found, but the external PR needs real after-fix macOS UI proof before merge. Likely related people: @steipete (high confidence) and @Yuxin-Qiao (medium confidence). Priority: P3 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherCodexBar’s General settings embeds a KeyboardShortcuts AppKit recorder for the global menu shortcut. CodexBar’s own localization override drives surrounding settings text, while the dependency otherwise follows macOS’s system locale. flowchart LR
A[Selected app language] --> B[CodexBar localization]
B --> C[General settings]
D[System-locale shortcut recorder] --> C
C --> E[Prompt coordinator]
E --> F[Localized idle and recording prompts]
Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Retain the narrow coordinator approach and add redacted after-fix proof showing CodexBar set to a language different from macOS before merge. Do we have a high-confidence way to reproduce the issue? Yes—source reproducibly shows main leaving the dependency recorder’s system-localized placeholder intact while CodexBar independently resolves its selected app language; the reported mismatch follows when those languages differ. Is this the best way to solve the issue? Yes—the coordinator changes only the two dependency prompt strings at the existing AppKit lifecycle boundary, avoiding a global language override or dependency fork. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f10b6056554e. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Co-authored-by: JiaJian <33014143+endless7@users.noreply.github.com>
steipete
left a comment
There was a problem hiding this comment.
Reviewed all supported locale resources and verified localized recorder prompts survive dependency writes during both recording lifecycle transitions.
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: Fix shortcut recorder app-language mismatch This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
|
Landed after verifying all 23 app languages, lifecycle regressions for dependency prompt overwrites, zero lint violations, all 930 local test selections with zero retries or timeouts, and successful exact-head workflow 32883623677. |
Summary
Why
When CodexBar is explicitly set to English on a Mac using Simplified Chinese, the General settings pane mixes English app labels with the recorder's Chinese placeholder. The recorder comes from
KeyboardShortcuts, whose resource bundle follows the system locale independently of CodexBar's in-app language override.The wrapper now reapplies CodexBar-localized placeholders during the AppKit editing lifecycle without changing
AppleLanguagesor the dependency.Validation
swift test --filter KeyboardShortcutsBundleTests— 3 tests passedmake check— locale checks, SwiftFormat, and SwiftLint passed with 0 violationsmake test— 930 selections in 78 groups; 78 first-pass successes, 0 failures, 0 retries, 0 timeouts