[lhr0909]

Why

In 0.6.2 the empty state, the "Ask us anything" subtitle and the attach menu read from localization/messages, but the catalog shipped English only. Simon tests ReceiptGenie in a non-English device language next, so these strings must be translated on iOS, Android, web and React Native (RK-3).

What changed

• Catalog: localization/messages/{locale}.json for 51 locales (ReceiptGenie's shipped set). All 64 keys are translated, with plural branches per CLDR category. All four generated outputs now include every locale.
• Web and React Native resolver (compileJavaScriptMessages): maps iw/in/tl/no, reads Traditional Chinese for TW/HK/MO, sends Portuguese outside Brazil to pt-PT, ignores -u- extensions, reduces regions to the base language, and falls back to English. It does not use Intl.Locale, because Hermes lacks it.
• Web widget: uses the browser language when context.locale is unset. It reads it after hydration (useSyncExternalStore), so server and client markup match.
• Android compiler: the emulator showed values-he and a bare no resolving to English. Hebrew and Indonesian are now written to values-iw and values-in, Bokmål is also written to values-no, and Hebrew keeps a many quantity, which older Android ICU and lint require.
• Tests: each client renders ja and zh-Hans, covering the empty state, subtitle and attach control or menu, plus a device-locale fallback table on Swift, Android and web.
• Release 0.6.3: version:set 0.6.3, docs/releases/0.6.3.md, the localization README, and the worklog. Not published.

Scope

Catalog, generators, the web locale default, tests and release prep. No apps/api changes and no GitHub release. The views that still use English literals are unchanged.

Tradeoffs

• The translations were drafted by agents from a key-context guide and machine-validated (keys, placeholders, plural categories, the "More" label reused in history_failed). No native speaker has reviewed them.
• The iOS screen and Menu coverage is an XCUITest in native/examples/ios. It needs demo_server.py and isn't in CI (CI only builds RespondKitUI for iOS). The macOS fallback-table test stays in swift test.
• RN test renders RespondKitScreen with react-dom/server and shimmed RN primitives. Adding jsdom or testing-library would have re-resolved rolldown across the lockfile, so the lockfile change is 3 lines (react-dom dev dependency).

Blast radius

• Every SDK client's UI language for the cataloged strings.
• Android hosts that override RespondKit strings for Hebrew or Indonesian must move the overrides to values-iw or values-in (noted in the release notes).
• Web hosts without context.locale now get the browser language instead of English for these strings and the transcript dates.

Verification

• pnpm ready: passed (vp check, release tests, localization:check, 445 package tests, builds).
• swift test: 26 tests passed, including LocalizationTests (ja and zh-Hans, plus 23 fallbacks via Bundle.preferredLocalizations on the compiled catalog).
• native/android/gradlew -p native/android :core:test :compose:assembleDebug :compose:lintRelease :example:assembleDebug: passed, lint 0 errors.
• :compose:connectedDebugAndroidTest on an API 36 emulator: 9/9 passed, including LocalizedScreenTest, which opens the real attach dropdown in ja and zh-Hans.
• iOS: xcodebuild -scheme RespondKit-Package test build on the simulator succeeded, and 24 tests passed. The example app's XCUITest (ja and zh-Hans screen plus attach Menu) passed on an iPhone 17 simulator.
• Web: 87 tests passed, including a hydration regression test. React Native: 22 tests passed.
• verify-npm runs on this PR because VERSION changed.

🤖 Generated with Claude Code

[simon-langoustine]

Changes requested at head b3525044f314c2efae68695efab39fa2fd924487. Verification verdict: verifier-failed.

Three act-on items are attached as review threads:

1. Browser locale detection causes an SSR hydration mismatch when the widget starts open without an explicit locale.
2. The new Swift localization test breaks iOS Simulator package test compilation because Process is unavailable.
3. The native tests do not cover the requested localized SwiftUI screen and actual Compose attach-menu rendering.

Local verification: pnpm ready passed with 445 package tests, localization:check passed, release version validation passed, macOS swift test passed 26 tests, Android core passed 24 tests and Compose instrumentation passed 9. I also reproduced the full iOS package test-build failure and the React hydration error. CI, including verify-npm, is green.

I drove Japanese and Simplified Chinese empty states and menus in the SwiftUI and Compose examples, and browser empty/error/retry, send/reopen and resize flows. These passed. SwiftUI required the documented host-language declaration, applied only to the temporary built host artifact. Arabic/Hebrew spotchecks were legible at tested sizes. React Native component tests and Android builds passed; emulator storage exhaustion blocked installation, so no live RN pass is claimed.

Catalog checks found all 51 added locales with 64 keys each and resources for all clients. No clear meaning-changing mistakes were found in the requested language spotchecks. This is not native-speaker certification. Only a version bump changed under apps/api; no server code changed. Release 0.6.3 remains prepared, with no GitHub release found.

Consider: declare test languages in the iOS example so its UI tests exercise the documented host setup. Existing English literals outside this catalog change are out of scope.

Full review and limitations, command logs and reproductions, screenshots on RK-4. These evidence links are local to the office board. Two independent interrogate reviewers agreed on the findings. The project verify skill/feature map were absent; checked-in examples and browser/device adapters were used. Product code was not edited.

[simon-langoustine]

Approved at 930d6ccd8778113c2181fbc41121a5d716410963. Verification verdict: live-ui-verified for this follow-up.

Re-reviewed only the fixes since b3525044f314c2efae68695efab39fa2fd924487. All three previous findings are resolved:

• The browser locale uses a stable server/hydration snapshot. The original independent reproduction now produces identical initial markup, zero recoverable hydration errors, and Japanese after hydration. All 87 web tests pass, including the new regression test. In a real browser I also confirmed the fallback and a live languagechange from Japanese to Simplified Chinese.
• The host-only catalog test is guarded for macOS. The previously failing iOS package command now builds and runs successfully: 24 tests pass on the iOS Simulator.
• The new SwiftUI XCUITest runs the real screen and opens the actual attachment menu in both Japanese and Simplified Chinese. I reran it successfully against this head. All 9 Compose instrumentation tests pass, including the new localized activity tests that open the actual dropdown. The example iOS host now declares its languages; no temporary binary metadata patch was needed.

Act-on: none. Both independent consistency reviewers found no remaining issues in the follow-up diff.

Consider: run the iOS example UI test in CI with its local demo server. It currently runs locally, which is sufficient for this re-review but leaves that regression check outside CI.

localization:check passes, relevant PR CI is green, and the worktree remains clean. Unchanged catalog/release-preparation conclusions carry forward from the first review. This focused re-review did not repeat the full locale audit or React Native live installation; the previously reported RN emulator-storage limitation remains. No merge or publication was performed.

Evidence: command logs, hydration reproduction and Compose test XML, SwiftUI screen, SwiftUI menu, browser fallback, browser languagechange. Links are local to the office board. Native results are also recorded in the local Xcode result bundles under /tmp/rk-4-package-tests/Logs/Test and /tmp/rk-4-ios-rereview/Logs/Test.