[Feature]: Support Typing charactors like Chinese or Japanese

[blackball]

Problem / motivation
When we need to auto fill some content with Chinese or Japanese charactor to test our apps. or to do some auto-reply tasks.

Proposed solution
maybe there's a putText("你好") command, which we can put the text we want into the input field.

Use case / impact
Non-native English world will be happy.

[blackball]

Or maybe we support clipboard.

putToClipboard("你好")

then type Ctrl+V.

[julienmerconsulting]

@blackball — great catch, and you've identified a real gap. Quick context :

⚡ Workaround that works today

Use paste() instead of type() for any non-ASCII string :

from sikuli import *

paste("你好")       # Chinese
paste("こんにちは") # Japanese
paste("안녕하세요") # Korean
paste("Привет")    # Cyrillic

paste() writes to the OS clipboard then issues Ctrl+V. Clipboard is Unicode-native on Windows / macOS / Linux, so any character works cleanly. Bonus : faster than type() for long strings since it's not key-by-key.

✅ What SikuliX (and OculiX) already supports for special characters

OculiX inherits the layout-aware KeyboardLayout engine from SikuliX1 (~850 lines, originally written by @RaiMan and contributors). It auto-detects the active OS keyboard layout via JNA user32.GetKeyboardLayout() and maps characters to the correct keystrokes for that layout :

type("été")     # auto-translates to AltGr+E,E on en-US, direct on fr-FR
type("ñ")       # auto-translates to AltGr+~,N on en-US, accent+N on fr-FR
type("ß")       # works on de-DE, falls back gracefully elsewhere
type("€")       # AltGr+5 on en-US, AltGr+E on fr-FR/de-DE — handled

160 characters mapped for the en-US base, extensible per-layout.

🌏 But CJK is a separate problem

Chinese / Japanese / Korean characters are not reachable through any keyboard layout because they require an Input Method Editor (IME) at the OS level. The IME transforms phonetic input ("ni hao") into ideograms (你好). To bypass IME for direct CJK input, each OS needs its own native path :

OS	API path	Implementation
Windows	SendInput + KEYEVENTF_UNICODE flag	extends existing SXUser32 JNA binding
macOS	CGEventCreateKeyboardEvent + CGEventKeyboardSetUnicodeString	new JNA bridge
Linux	XTestFakeKeyEvent + Xlib Unicode keysyms	new JNA bridge

Doable, real native work that needs proper CI validation per OS to avoid silent regressions.

🛠️ Implementation incoming on claude/feature-232-cjk-unicode-typing

• KeyboardLayout Latin extended — already shipped (inherited from SikuliX1)
• Windows SendInput/Unicode native path → fallback when char not in layout
• macOS CGEvent/Unicode native path
• Linux XTest/Unicode native path
• Self-contained Swing test (JFrame + JTextField + assert) — no OS-level accessibility permissions needed
• GitHub Actions matrix workflow windows-latest + macos-latest + ubuntu-latest (with Xvfb on Linux)

Wire-up is transparent — type("你好") will just work :

// In KeyboardLayout.toJavaKeyCode
int[] mapping = lookupInActiveLayout(key);
if (mapping != null) return mapping;            // existing layout-aware path
return SXUnicodeInjector.inject(key);           // new fallback for CJK / emoji / etc.

🌍 Why CJK matters strategically

This isn't niche — it's a real strategic gap. Per current SourceForge stats :

Country	% of downloads
🇸🇬 Singapore	35%
🇨🇳 China	14%
🇹🇼 Taiwan	3%
🇯🇵 Japan	2%

→ ~55% of SourceForge downloads are in CJK markets. Your filing this is exactly the kind of feedback that shapes the next milestone — thanks.

📌 Tracking

Tagged enhancement + area:api + priority:p2, parked in v3.0.4 milestone. Will ping back here when the PR is up with CI green on all 3 OS — should be within the next session.

In the meantime : paste() is your reliable path. If you hit cases where it doesn't work (terminals, custom widgets, anti-bot fields), drop a note here — those are exactly the cases where the native CJK path is mandatory.