Japanese product localization and Unicode compatibility — implementation available

[Nicolas0315]

I have an implementation of Japanese product localization and Unicode compatibility available for review:

• Tracking issue
• Implementation PR in my fork
• Comparison against upstream master

Following CONTRIBUTING.md, I am posting here because external Issues and pull requests are disabled. This is a contribution proposal; nothing has been merged upstream.

The implementation currently covers:

• Built-in Japanese client dictionaries, language selection/persistence, dates, accessibility text, plugin metadata, desktop menus and supporting screens.
• IME composition, Japanese file references and original filename spelling, Japanese font precedence, locale-aware file ordering and normalized workspace-title matching.
• Persisted/live session search for interior Japanese phrases, short queries, halfwidth kana, decomposed dakuten, fullwidth Latin/numeric messages, variation selectors and supplementary Han. Original snippets and authoritative JSONL files remain unchanged; only the disposable search index advances from schema 8 to 9.
• English/Chinese/Japanese CLI and TypeScript/Python SDK diagnostics, with captured per-instance language and unchanged command names, wire fields, error codes and external diagnostic details.
• Japanese Windows installer/uninstaller resources and macOS localization resources, including live three-language native menu switching.

The current published implementation is based on upstream d743267388641bc76f17c45ce8b4c231aed1d32c; validated fork head is b26a34261aa9193dd16a70f457b493982b75c011. Local validation includes the production build, normal pre-push typecheck, 43 documentation gates and all 19 hygiene gates. The final diagnostics/SDK/native/rescope aggregate passes 379 tests; Python passes 314 tests with 5 platform-specific skips, including real Node and executable runtime carriers. Earlier browser, IME, file and SQLite regression evidence remains listed in the PR. The unchanged 1,000-session search benchmark passes: 49.52 seconds first search, 1.198 seconds repeat, 1,292.8 MB peak RSS.

The 17 baseline vendor-rescope reports are fixed without changing product identifiers or disabling the gate; 27 tests and a negative control cover package-reference rewriting. Real Windows 11 acceptance passes 45 isolated production-NSIS installer/upgrade cases plus 15 uninstall-only cases across English, Chinese and Japanese, with no fixture paths/registry keys left behind. A real unsigned macOS ARM64 app has been visually exercised through onboarding/settings and live Japanese/Chinese/English native-menu switching. Actual Electron menu APIs pass ARM64 and x64 Rosetta. Final unsigned ARM64/x64 payload packaging, runtime smokes, DMG integrity and ad-hoc signature checks pass. The complete unsigned Windows x64 payload also builds and passes its native runtime, offline plugin and Office conversion smokes. Its public test-only .invalid mandatory-policy origin remains fail-closed, so production application GUI/EV signing is a separate gate.

The additional carrier tests exposed an SDK startup race: initialization could succeed before the launcher rejected a missing required plugin. The transport now waits for the launcher's successful startup commit. Required-failure/optional-warning cases, buffered initialization and early disposal are covered; protocol values remain unchanged.

Signed macOS distribution acceptance still requires unavailable Developer ID/notarization credentials. No signed-release acceptance is claimed. The final unsigned ARM64 Electron app now passes an app-specific CDP IME composer test: composing Enter is observed, no session is submitted, and the committed Japanese text is exact. A further native CUA check drives the actual macOS Kotoeri OS IME from Roman keys through kana, Kanji candidates and Enter confirmation. Passive event readback confirms isComposing=true for Enter, compositionend with 日本語, exact composer text and unchanged session count; CDP does not inject this input. Manually pressed hardware keys and Windows OS IME remain unverified. The test app/DMG are closed, with the installed app, previous protocol handler and input source preserved. The production Windows application payload/EV signing is also separate from the isolated NSIS fixture.

The agreed external exceptions are the separately supplied Chromium DevTools frontend and the external account/billing service's supported languages. User/model text, code, identifiers and third-party/OS diagnostics retain their original values. This does not generalize the public documentation's English/Chinese pairing system discussed in the Japanese documentation proposal; the proposed scope is the product and its supporting systems.

If this direction is useful, the implementation and its regression tests are available through the comparison above. I am happy to follow the maintainers' preferred integration approach.

[Nicolas0315]

The integrated Japanese compatibility candidate is now published at 873be5eb5a16c4188b67977fa969bce28e666f39 in PR #2, based on upstream 571902028a75c64c1d767f4ae5fd099485f0ddf0 (alpha.3). The fork default branch was preserved; the PR pins a separate upstream snapshot base.

The exact Japanese trajectory/question-reply timestamp regressions requested in review were added, their locale-reversion negative controls fail, and both threads are resolved. The complete coverage lane passes 43,560 tests, with 100% statements/branches/functions/lines. Build, typecheck, hygiene, documentation/site, keyless session replay and the selected native Windows/macOS ARM64 unsigned distribution checks pass. The PR body contains counts, platform limits, artifact SHA-256 values and the serialized Japanese-search measurement.

A standard public Intel macOS runner is qualifying the same fixed source without secrets or artifact storage: native Intel run. Its result is pending. Inherited primary CI includes custom larger-runner labels unavailable in this fork; that run was cancelled while those jobs were still queued to avoid any non-standard runner charge. Fork Issue policy currently fails because its inherited organization-specific repository/app configuration requests deepseek-harness/deepseek-harness, which returns 404 here. Neither is claimed as passing, and no repository gate is bypassed.

The real-model demonstration GIF remains open: no confirmed no-cost real-model path is available. Current physical-keyboard OS IME acceptance, signed/notarized distribution and maintainer approval/merge/release remain separate gates. No paid API request, certificate purchase or installed application replacement was made. Companion rdsh: PR #500, where the new Linux native ownership probe passes and the latest review corrections are being applied.

[Nicolas0315]

Native Intel macOS qualification is now successful for source 873be5eb5a16c4188b67977fa969bce28e666f39: standard public runner. The official unsigned alpha.3 pipeline, pre/post-ASAR native runtime/offline-plugin/Office smoke and DMG verification pass. Additional Japanese DOCX/XLSX/PPTX conversion uses packaged Python and Office with empty PATH; all three PDFs were recovered from SHA-checked chunks, their Japanese text extracted, and their actual rendered pages visually inspected. Intel DMG SHA-256: 49008a3bc59df7bbc2df66c5a7582509ac67ccd526d0ca9caa8a3ed30b1569a5.

Together with the existing Windows x64 and macOS ARM64 receipts, all three unsigned native package targets have passing runtime/Office qualification. This establishes native Intel VM execution, not physical-keyboard OS IME or signed/notarized release acceptance. No paid API request, purchase or Actions artifact upload was used by this qualification workflow.

The separate free Linux/Windows exhaustive coverage run is still in progress. The PR body has been updated. The real-model GIF, current OS IME, missing fork organization/Cloudflare credentials and maintainer gates remain explicit.

[Nicolas0315]

The Windows exhaustive coverage retry is now successful at repaired source 1a7e3d2307ad6f43d857f2757ef571e2e4f170b7: standard public Windows2025 run.

• 40,850 tests passed, 191 explicit platform skips and one expected failure; 1,958 test files passed and 21 were skipped.
• Statements, branches, functions and lines are all 100%. All four official gates, including heavy-exempt, pass; zero skipped gates and an unchanged dependency lock.
• The original 13 failures were isolated to Linux errno mocks and Windows ACL fixtures. The repair retains denial assertions, sets exact fixture ACLs and disables bypass privileges only in owned PowerShell children. Native focused verification is 53/53 with zero skips; three omitted-repair controls reproduce failures.

Only seven test/README paths changed after application source 873be5eb5a16c4188b67977fa969bce28e666f39. Linux exhaustive coverage at that source already passes 42,260 tests, with 164 explicit skips, one expected failure and all four metrics 100%. macOS coverage, the three unsigned native packages, Japanese Office previews and the real local-model Japanese demo retain their explicit 873be5e attribution; application code is unchanged.

PR #2 and tracking Issue #1 contain the updated source and qualification limits. Signing/notarization credentials, current physical OS-IME acceptance and fork-specific organization/deployment credentials remain separate prerequisites. No paid model request or certificate enrollment was performed. Nothing has been merged or released.