Bug: Chinese Simplified text shows garbled characters (mojibake) in UI — v0.6.0-alpha.5

[shqpyy]

Bug: Chinese text (Simplified) shows garbled characters in UI

OpenClaw Companion v0.6.0-alpha.5 (Installed from setup exe)

Description

Chinese Simplified (zh-CN) text in the Companion app UI displays garbled characters in some UI areas. English text displays perfectly. Some Chinese characters render correctly (e.g. “搜索”) while others appear as mojibake.

The issue occurs with both the portable (zip) version and the installed (exe setup) version.

Screenshot available upon request.

What I've tried

Attempt	Result
chcp 65001 then launch app	❌ Still garbled
Hide zh-CN resource directory, forcing en-US fallback	❌ Still garbled
Set HIGHDPIAWARE compatibility flag	❌ Still garbled
System zh-CN locale, ACP=936 (GBK)	✅ Correct
All required Chinese fonts present (Microsoft YaHei, SimSun, etc.)	✅ Installed
WebView2 Runtime v148.0.3967.83	✅ Installed

System info

• OS: Windows 10 Home China (build 26200, Insider Dev Channel)
• System locale: zh-CN (Chinese Simplified, China)
• ANSI Code Page: 936 (GBK)
• Display language: zh-CN
• WebView2 Runtime: 148.0.3967.83
• CPU: x64

Observed pattern

• ✅ English text in all UI areas — OK
• ✅ Some Chinese text — OK (e.g. “搜索”)
• ❌ Some Chinese text — garbled mojibake characters (consistent across restarts)

Notes

• Both the zip (portable) and exe (installed) builds exhibit the same issue
• The .pri resource file contains correct UTF-8 encoded Chinese strings (verified via binary analysis)
• Windows build 26200 is a pre-release Insider build, which may be a factor
• No existing issues were found in the repo about Chinese text rendering

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 29, 2026, 5:32 AM ET / 09:32 UTC.

Summary
Keep open: current main is tagged v0.6.0-alpha.5, the reported version, and the checked-in Simplified Chinese resource file already contains the mojibake pattern described by the reporter.

Reproducibility: yes. Source inspection on current main reproduces the core problem because zh-cn/Resources.resw contains mojibake values that the UI would load as localized strings.

Next step
This is a narrow source-confirmed resource-file repair with clear validation commands.

Review details

Best possible solution:

Repair the corrupted CJK resource values, at minimum zh-CN and likely zh-TW, then add a localization regression check that fails on mojibake-like Latin-1/UTF-8 corruption in non-Latin locale files.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection on current main reproduces the core problem because zh-cn/Resources.resw contains mojibake values that the UI would load as localized strings.

Is this the best way to solve the issue?

Yes. The narrow maintainable fix is to repair the corrupted resource values and extend localization validation so the same encoding corruption cannot pass again.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact packaging/build step that allowed corrupted CJK resource values to ship is not identified yet; the fix should verify the built PRI or real Windows UI after repairing source values.
• Traditional Chinese resources show the same mojibake pattern in source, so fixing only zh-CN may leave adjacent CJK locale drift.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 32e6025d00c6.

Label changes

Label changes:

• add P2: The issue is a confirmed user-facing localization defect in a supported language with limited blast radius.
• add impact:other: The affected impact is visible UI localization quality rather than state, auth, message delivery, crash, or security behavior.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: The issue is a confirmed user-facing localization defect in a supported language with limited blast radius.
• impact:other: The affected impact is visible UI localization quality rather than state, auth, message delivery, crash, or security behavior.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• ./scripts/Test-Localization.ps1 -StrictHardcodedXaml
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Current zh-CN resources contain mojibake: src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw declares UTF-8 but line 21 stores the connection header as mojibake (连接) rather than readable Simplified Chinese. (src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw:21, 32e6025d00c6)
• Reporter pattern matches source: The same zh-CN file has newer readable Chinese entries such as 筛选设置 and 搜索… (Ctrl+E), matching the report that some strings render correctly while others are garbled. (src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw:1627, 32e6025d00c6)
• Chinese Simplified is a supported locale: The localization guide lists Chinese Simplified as a supported language at Strings/zh-cn/Resources.resw, so readable zh-CN UI text is expected behavior. (docs/LOCALIZATION.md:12, 32e6025d00c6)
• Existing validation does not catch mojibake: Localization tests check key parity, empty values, placeholders, and all-or-none translation coverage, but the inspected validator has no corruption/mojibake assertion for CJK resource values. (tests/OpenClaw.Tray.Tests/LocalizationValidationTests.cs:298, 32e6025d00c6)
• History points to the localization import: git blame shows the garbled zh-CN values around lines 20-60 date to commit 8714381248a21d2747fa6d4749dfd20e804d7355 (Merge branch 'pr-519'), which added the large localization resource set and validator. (src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw:21, 8714381248a2)
• Reported version is current main: git tag --points-at HEAD and git describe --tags --always HEAD both report v0.6.0-alpha.5, so the issue is not already fixed after the reported build. (32e6025d00c6)

Likely related people:

• Scott Hanselman: The large zh-CN resource import, localization docs, and validator were introduced in commit 8714381248a21d2747fa6d4749dfd20e804d7355, and blame ties the garbled values to that commit. (role: localization surface introducer; confidence: high; commits: 8714381248a2; files: src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw, tests/OpenClaw.Tray.Tests/LocalizationValidationTests.cs, docs/LOCALIZATION.md)
• ranjeshj: Commit 9de9b5ba0f8aa69fffafef884b750a6db8996a15 recently touched zh-CN resources and the localization validator while revamping the config page. (role: recent area contributor; confidence: medium; commits: 9de9b5ba0f8a; files: src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw, tests/OpenClaw.Tray.Tests/LocalizationValidationTests.cs)
• the99missedcalls: Commit 6a1429c75cfa39624e55db3f0acdf730a8be1158 recently added readable zh-CN voice/chat strings near the same resource surface. (role: recent adjacent contributor; confidence: medium; commits: 6a1429c75cfa; files: src/OpenClaw.Tray.WinUI/Strings/zh-cn/Resources.resw)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[shqpyy]

Here is a screenshot showing the garbled Chinese characters (mojibake) in the UI:

[github-actions]

🤖 This is an automated response from Repo Assist.

Root Cause

Confirmed. The zh-cn, zh-tw, and fr-fr Resources.resw files are suffering from Windows-1252-misread-as-UTF-8 double-encoding. The original UTF-8 byte sequences were interpreted as Windows-1252 code points and then re-encoded as UTF-8 when written into the XML.

Concrete example — 启动 ("start up"):

Step	Value	Hex
Original UTF-8 bytes	启动	E5 90 AF E5 8A A8
After Windows-1252 misread	å \x90 ̄ å Š ̈	—
Stored in .resw (re-encoded UTF-8)	å ̄åŠ ̈	C3 A5 C2 90 C2 AF C3 A5 C5 A0 C2 A8

This explains why ACP=936 (GBK) "works" on your system: the OS decodes the file with GBK which happens to re-interpret some byte sequences more forgivingly.

Scope

• zh-cn/Resources.resw — 1,012 of ~1,700 strings double-encoded
• zh-tw/Resources.resw — 1,023 strings double-encoded
• fr-fr/Resources.resw — 17 strings with accented characters (é, ê, ç, etc.) double-encoded
• nl-nl and en-us — unaffected (ASCII only / already correct)

Fix

I've opened a draft PR that repairs all affected strings by reversing the encoding chain — mapping each character back through the Windows-1252 reverse table to recover the original UTF-8 byte sequence. The fix is conservative: strings that don't cleanly round-trip are left untouched.

See the companion PR on branch repo-assist/fix-issue-583-mojibake-resources.

Preventing Recurrence

The translation tooling that generated these files needs to be configured to read and write .resw files as UTF-8, not as Windows-1252. The .resw XML header declares encoding="utf-8" so any conformant tool should handle this correctly.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a