Summary

On macOS, Rewind's screen OCR recognises no Japanese text at all. Latin characters and digits on the same frame come back fine, so this is not "OCR is broken" — the recognition language is pinned to en-US, and non-Latin scripts are simply out of scope.

There is no setting that changes this (it is a compile-time constant, see Root cause). The practical effect is that for users working in a non-Latin script, Rewind's search is silently non-functional.

Steps to reproduce

1. Run the macOS desktop app normally on Apple Silicon with a Retina display.
2. Bring a window containing Japanese text to the front (the test document below).
3. Wait a few minutes, then inspect screenshots.ocrText.

Test document (TextEdit — heading 28pt, body 16pt, small 11pt):

OMITEST-SAMPLE-20260905
これはOCRの精度を測定するためのテスト文書です。
英数混在: project-name の Issue #42 は期限 2026-09-16、担当は Alice。
記号と数値: 進捗 78.5% ／ 予算 ¥1,234,567 ／ 電話 03-1234-5678
小さめ本文: ひらがな・カタカナ・漢字・alphabet を混ぜています。

Actual output

OMITEST-SAMPLE-20260905
*WE: project-name D Issue #42 laP 2026-09-16. J*I- Alice.
084*1 * 785% / 7#·1,234,567 / TIE 03-1234-5678

• The ASCII heading is an exact match.
• The two Japanese-only lines are missing entirely.
• On the mixed lines, the Latin text survives and the Japanese collapses into noise:
  英数混在: → *WE:, の → D, は期限 → laP, 担当は → J*I-.
• Some numbers are damaged too: 78.5% → 785%.

For comparison, reading the same window through an accessibility-tree path returns every line verbatim, including the 11pt one — the text is present and legible on screen.

Scale on real data

Aggregated over every OCR'd frame in this machine's Rewind database:

Over 1,600 characters extracted per frame on average, and not a single Japanese character among them — on a machine whose UI, documents and chat are predominantly Japanese.

Root cause

desktop/macos/Desktop/Sources/Rewind/Core/RewindOCRService.swift:

private static let recognitionLanguages: [String] = ["en-US"]

Being a private static let, this cannot be changed by a setting, an environment variable, or any user action.

The same constant is duplicated in three other places, all ["en-US"]:

• desktop/context-for-claude/Sources/ContextApp/Capture/ScreenWatcher.swift
• desktop/context-for-claude/Sources/ContextApp/Onboarding/SettingsRowSighting.swift
• desktop/macos/Desktop/Sources/CloudConnectorFormAutomation.swift

The language controls that do exist in the app (/v1/users/language, "Change spoken language", "Auto-Detect (Multi-Language)") all apply to speech transcription only and have no effect on screen OCR. The audio path is multilingual; the screen path is English-only.

Why this matters

desktop/context-for-claude/docs/ocr-quality.md already states the stakes better than I can:

A term the recogniser got wrong is not merely ugly — it is unfindable, and the product tells Claude that an empty result inside the coverage window is evidence something did not happen (Tools.statusDescription, renderStatus). So a mis-OCR'd token converts silently into a confident false statement. This is a correctness defect in the honesty contract, not a cosmetic one.

In a Japanese-language environment this failure applies to all screen text, continuously. An empty search result that should mean "this was never on screen" instead means "this was never indexed, because it wasn't Latin."

That same document contains a careful input-resolution sweep — but every measurement in it was taken with Vision .accurate, en-US, revision 3. Non-Latin scripts were never part of the evaluation. CJK glyphs carry more strokes per em than Latin ones, so they should be hit harder than English by the 1x capture and the 1600px clamp the document identifies. It may be worth treating the language list and the input resolution as one problem rather than two.

Suggested directions

I'd rather agree on scope than assume it, so these are options, not a proposal:

1. Make the recognition language configurable — derived from the app's existing language preference or the system locale. recognitionLanguages is an ordered priority list in Vision, so naively shipping ["en-US", "ja-JP"] risks regressing English accuracy; letting the user pick a primary language seems safer.
2. Consolidate the four duplicated constants into one source of truth.
3. Re-run the docs/ocr-quality.md sweep with a non-Latin fixture, to check whether the optimal input size is language-dependent.

CONTRIBUTING.md asks for scope alignment before implementation, so I'm opening this as an issue first. Happy to write the PR once there's a direction.

Environment

• macOS 26.5.2, Apple Silicon
• Omi desktop 0.12.272 (build 12272)
• Displays: built-in Retina (1512×982 @2x) plus two external monitors
• Japanese rendered in the standard system font (Hiragino), 11–28pt