Skip to content

fix(i18n): localize browser load-failure and certificate copy - #10672

Closed
MumuTW wants to merge 1 commit into
stablyai:mainfrom
MumuTW:fix/i18n-browser-load-failure
Closed

MumuTW wants to merge 1 commit into
stablyai:mainfrom
MumuTW:fix/i18n-browser-load-failure

Conversation

@MumuTW

@MumuTW MumuTW commented Jul 26, 2026 •

Copy link
Copy Markdown
Contributor

Summary

The 19 browser.loadFailure.* keys have been shipping as untranslated English in every target catalog since the browser certificate-error work (#9104, #9070). A user on a Chinese, Japanese, Korean, or Spanish UI who hits a TLS failure gets an English error page inside an otherwise localized app — and a certificate warning is a bad place to lose the reader.

This localizes all 19 for zh, ja, ko, and es.

Nothing else changes: no new keys, no en.json edit, no reordering. Exactly 19 values per file.

The strings cover connection/certificate headings (connectionNotSecure, certificateAuthorityInvalid, …), the action buttons (retry, copyAddress, openExternally, tryHttps, proceedUnsafe), and the challenge-lifecycle messages (certificateChallengeExpired, certificateProceedFailed, …).

Translation constraints followed:

  • Orca and HTTPS stay verbatim, per locale-translation-policy.mjs.
  • Every {{value0}} is preserved one-for-one — verified programmatically across all 19 × 4.
  • Button labels were kept short enough for the button; the certificate vocabulary uses each locale's platform-standard term (证书 / 証明書 + 認証局 / 인증서 + 인증 기관 / certificado + autoridad).

Note on scope

This is one instance of a broader pattern — feature copy lands in en.json and the target catalogs are never filled — which is the premise of #8512. This PR only fills the hole for these 19 keys; it doesn't attempt to fix the process.

Screenshots

No visual change — string values only, no layout or component change.

Testing

  • pnpm lint — fails identically on a clean upstream/main checkout, unrelated to this PR: verify:localization-coverage reports 6 pre-existing unlocalized "Ghostty" keyword strings in terminal-advanced-platform-search.ts and terminal-pane-appearance-search.ts. I verified this by running the same check on a detached main worktree. The localization checks this PR does affect pass — verify:localization-catalog confirms parity at 11,158 keys for all four catalogs.
  • pnpm typecheck — clean (all three projects).
  • pnpm test — 3422 files / 36470 tests pass. 2 tests fail in src/relay/agent-exec-handler.test.ts, and both fail identically on a clean upstream/main checkout (verified in a separate detached worktree: same 2 failed / 8 passed). Pre-existing and unrelated to localization — this PR touches no relay or spawn code.
  • pnpm build — clean, including the Swift computer-use-macos native target.
  • Tests — no new tests added. These are catalog values, and the existing verify-localization-catalog.mjs parity check plus the locale tests already cover the invariants that can regress here (key parity, placeholder compatibility). A test asserting specific translated strings would just restate the catalog.

AI Review Report

Reviewed with Claude Code. What it checked and what came back:

  • Scope containment — mechanically diffed flattened HEAD~1 vs HEAD for each of the four catalogs. Result: exactly 19 changed keys per file, zero outside browser.loadFailure.*. This was the main risk, since a careless edit to an 11k-key JSON file can reorder or drop entries.
  • Placeholder integrity — programmatic check that every {{...}} token in each en.json source appears with matching multiplicity in all four translations. Zero mismatches. A dropped placeholder here would render a hostname-less certificate error.
  • Completeness — verified no value is still byte-identical to its English source.
  • Cross-platform — no platform surface touched. No shortcuts, no key labels, no path handling, no shell invocation, no Electron API. These are JSON string values consumed through the existing i18next runtime, identical on macOS, Linux, and Windows. The strings themselves contain no path separators or platform-specific terminology.
  • Not verified — I'm a zh-TW speaker and read the zh output closely; ja, ko, and es were spot-checked for terminology and button length but would benefit from a native reader. One deliberate judgment call flagged for review: zh renders "Retry the page" as 重试页面 to stay consistent with the 重试 button label, where Chrome's convention would be 重新加载页面. Happy to switch if a reviewer prefers.

Security Audit

Low surface. No input handling, command execution, path handling, auth, secrets, or IPC is touched — the change is four JSON catalog files, values only, no new dependency.

The one security-adjacent consideration is that this copy sits on a TLS failure path, where mistranslation has real consequences: a user deciding whether to click through a certificate warning must understand what they're agreeing to. So the review specifically checked that the risk-bearing strings preserve their warning force rather than softening it — proceedUnsafe keeps the explicit unsafe marker in every locale (仍要继续(不安全) / 続行(安全ではない) / 계속(안전하지 않음) / Continuar (no seguro)), and certificateAuthorityInvalid keeps Orca as the subject that does not trust the issuer, rather than the vaguer "this certificate is untrusted".

No follow-up needed.

Notes

The same gap almost certainly exists elsewhere in the catalogs; this PR does not audit for it. If maintainers want, the check is cheap to run repo-wide — comparing each target catalog against en.json for byte-identical values, excluding brand-name passthroughs.

ELI5

Browser load-failure and certificate error pages were English-only even in localized UIs. Those strings are translated for Chinese, Japanese, Korean, and Spanish so TLS errors match the rest of the app.

The 19 browser.loadFailure.* keys shipped as untranslated English in
zh.json, ja.json, ko.json, and es.json since the browser
certificate-error work landed. This localizes them for all four
catalogs, keeping Orca, HTTPS, and the {{value0}} interpolation tokens
verbatim.
@coderabbitai

coderabbitai Bot commented Jul 26, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Updated the browser.loadFailure translations in Spanish, Japanese, Korean, and Chinese. The changes cover connection and certificate errors, certificate challenge states, retry and address-copy actions, external opening, HTTPS fallback, unsafe proceeding, and connection status messages while retaining the existing keys and placeholders.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly summarizes the main change: localizing browser load-failure and certificate-related strings.
Description check ✅ Passed The description matches the template well, with all required sections present and sufficiently filled out.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@nwparker nwparker added the bug Something isn't working label Jul 27, 2026
@AmethystLiang
AmethystLiang requested a review from OrcaWin July 28, 2026 16:50
nwparker pushed a commit that referenced this pull request Aug 4, 2026
The browser.loadFailure.* keys were still raw English in es/ja/ko/zh. en.json is
untouched; every {{value0}} token and the Orca/HTTPS brand terms are preserved.

13 of the zh keys were already covered by #12368, so only the 6 it did not
reach are taken here.

Co-authored-by: MumuTW <42820974+MumuTW@users.noreply.github.com>
@nwparker

nwparker commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Merged into main via #12514, which consolidated the open community translation work into one branch. Your commit is on main with you as its author — I used a rebase merge specifically so every contributor's commit and co-author trailer survived intact rather than being squashed into one.

Closing this in favour of that. Thank you for the fix, and sorry it took as long as it did to get through.

@nwparker nwparker closed this Aug 4, 2026
@MumuTW
MumuTW deleted the fix/i18n-browser-load-failure branch September 12, 2026 13:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants