"老" is output as "j́"

[mirka]

Describe the bug

When a translation contains the character 老, it's output as j́ when I type it. This doesn't happen with any other characters (that I know of).

To Reproduce

Steps to reproduce the behavior:

1. Add a translation that includes the character, for example "HRAO": "老".
2. Stroke the chord.

Expected behavior

The character is output as is.

Screenshots

https://github.com/user-attachments/assets/e8beb0ea-cf96-4c94-964f-06025fa679fe

This is happening regardless of text editor or browser.

Operating system

• OS: macOS Sequoia 15.5
• Plover Version 4.0.1

Hardware

Starboard with Gemini PR

[mkrnr]

I tested it on macOS Sequoia 15.5 with Plover v4.0.2 and I'm able to type 老 (actually typed it right now with Plover).

Maybe it's an encoding issue with your dictionary? It should be UTF-8 encoded. You can check it like this:

file -I inbox.json
inbox.json: application/json; charset=utf-8

[mirka]

Thanks for testing! Yes, encoding was fine.

file -I japanese.json
japanese.json: application/json; charset=utf-8

I also tried it in a secure input field to make sure that other apps weren't intercepting/modifying the text, and it still reproduces. If it's just happening in my environment, I'm out of ideas 🥲

[mkrnr]

Some interesting insights from ChatGPT:

A likely cause is that Plover is trying to “type” 老 using ordinary key-events, but the active macOS keyboard layout can’t produce that character. On the default ABC / U.S. layout Plover ends up sending the sequence Option-E (dead acute) + J, which macOS interprets as j́ (U+006A U+0301).

And that explains why it was working for me yesterday: I'm using an European keyboard layout (EurKEY) and with that I get 老. If I switch to the default ABC / U.S. layout, I can reproduce this issue and also get j́.

[mirka]

Oh wow. You're right, I tried it on a French layout and it works. It doesn't work on either of the layouts that I use day-to-day (US and Japanese).

I wonder why it's just this character, because I have lots of other CJK characters in my definitions that work normally. Or emojis too, for that matter.

Do you know if this is something patchable at the Plover level?

[mkrnr]

Some more insights:

Character	Hex value	macOS treats it as…	Result on the U.S./ABC layout
老	0x8001	“pointer to sequence #1”	Sequence #1 is defined — it’s Option + E (dead acute) then J. Plover replays those keys and you get j́.
耂	0x8002	“pointer to sequence #2”	Sequence #2 is not defined in this layout, so macOS falls back to “okay, just treat 0x8002 as a real Unicode code-point.” Plover inserts 耂 correctly.

So that's why it works for the French layout or mine: there, 0x8001 is not defined so it falls back to Unicode.

I'm afraid I won't be able to work on this anytime soon due to the rather complex implementation.

But I can offer a workaround that pastes the problematic string:

1. Create an Apple Script ~/path/to/file/output-via-paste.scpt using the Script Editor with this content:

on run argv
	if (count argv) = 0 then return
	set pasteText to item 1 of argv
	
	set oldClip to the clipboard
	set the clipboard to pasteText
	tell application "System Events" to keystroke "v" using {command down}
	delay 0.1 -- brief pause so paste completes
	set the clipboard to oldClip
end run

2. Install the plugin plover-run-shell via the Plugins Manager
3. Define a dictionary entry "HRAO": "{PLOVER:SHELL:osascript ~/path/to/file/output-via-paste.scpt 老}"

[mirka]

I guess it's the clipboard workaround for me then. I've just started building out my Japanese dictionary so I hope there aren't many characters like this 😅

Thank you for looking into it!