mirror of
https://github.com/keycastr/keycastr.git
synced 2026-05-15 14:15:50 -06:00
[GH-ISSUE #314] Wrong input language is displayed #269
Labels
No labels
bug
compatibility
discussion
documentation
enhancement
help wanted
help wanted
investigation needed
pull-request
release
visualizer
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/keycastr#269
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eranshefi on GitHub (Nov 26, 2024).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/314
Hi
Thanks for this great tool!
I have an issue, that sometimes the wrong language is being used, although I'm in the right one.
To solve this issue, I go to settings and press the Apply Modifiers checkbox (no matter if it is on or off) and the issue is solved, until the next time.
Thanks.
@akitchen commented on GitHub (Mar 28, 2025):
Hello, with apologies, I thought I already replied to your issue but somehow it didn't post to GitHub.
Could you describe your setup a bit more? What version of macOS, and of KeyCastr, and are you using anything other than macOS's built-in capabilities to set your locale and input source? (i.e., are you using any virtual key mapper for a custom layout?)
KeyCastr does detect when the user changes their input source, and I have tested to see that it displays the expected results when first started with a given input source, in my case QWERTZ instead of QWERTY.
@eranshefi commented on GitHub (Apr 2, 2025):
Hi
I’m using version 0.10.3
MacOS Sonoma 14.16.1
No other locale input source app.
I can send you the system info if you need further data.
Right now the issue is still there..
Eran Shefi

@akitchen commented on GitHub (Apr 3, 2025):
Thanks - just some more questions.
What language are you seeing vs. expecting? macOS has Language & Region settings under the General tab in System Settings, as well as a separate set of keyboard input sources which can override the default for your language/region settings. It might help to look into these settings and try to figure out if they are affecting what KeyCastr is showing.
Does KeyCastr start automatically when your computer starts? I wonder if it somehow could be starting before your input source or locale are set by macOS, especially if it is overriding the default for your selected language & region. KeyCastr uses the current keyboard layout input source provided by a rather old Carbon API; it's possible that there is a bug in there where it isn't set yet if the app is starting up before your input source is set, but this is just speculation.
@eranshefi commented on GitHub (Apr 3, 2025):
Hi
At start it works fine, but suddenly this start to mess… 😇
Actually, I like it to always remain on English.
And as for your question about languages, I use English and Hebrew, and
sometimes Arabic but now only the first two.
Thanks!
On Thu, 3 Apr 2025 at 22:35 Andrew Kitchen @.***> wrote:
@eranshefi commented on GitHub (Jul 20, 2025):
Hi
It’s been a while. Any chance to solve this issue?
A riminder: I need only English letter showing, but other keyboards is getting in, although I’m in English input.
Thanks
Eran
@MaxZarev commented on GitHub (Nov 19, 2025):
same problem, I have 2 language in my mac - ru, en, KeyCastr shows ru every time, how I can use only en lang?
@akitchen commented on GitHub (Nov 21, 2025):
I assume when you refer to languages you mean Input Sources, added from the Keyboard section in the System Settings app.
KeyCastr displays events according to the current keyboard layout (Input Source), which is has to cache for performance reasons. It relies on notifications from the OS to know when that layout or input source changes.
It turns out that the app doesn't receive these notifications from the OS right away when it is not in the foreground, which is most of the time. This is actually a bug in how these notifications are configured, which is a simple fix I'll include in the next release.
Meanwhile, opening KeyCastr's settings pane should fix the issue because the OS will deliver the pending notification immediately. You don't even need to change visualizers -- it should begin displaying keystrokes according to the new layout at that point. Restarting the app will also fix it, but isn't strictly necessary.