[Chang-Jin-Lee]

Summary

• getBrowserLinkRoutingDescription() in src/renderer/src/components/settings/browser-search.ts returned a hardcoded template literal instead of going through translate(), so the description stayed in English regardless of the selected UI language, even though every other string on the same settings pane (Settings → Workflow → Browser) was translated.
• Wrapped the string in translate(), interpolating the platform-specific shortcut label via {{value0}} (mirroring the existing pattern used elsewhere, e.g. App.tsx's Toggle sidebar ({{value0}})).
• Added the new key to en.json and ran pnpm run sync:localization-catalog to keep es.json/ja.json/ko.json/zh.json in parity (English placeholder copied in, per the documented sync behavior — actual translation happens in a separate machine-translation pass per config/localization-audit.md).

Fixes #9652

Test plan

• pnpm exec vitest run --config config/vitest.config.ts src/renderer/src/components/settings/browser-search.test.ts — 2 passed
• pnpm run typecheck — clean
• pnpm run verify:localization-catalog — clean
• pnpm run verify:localization-coverage — no new unlocalized strings introduced by this change (3 pre-existing unrelated findings in ai-vault-session-launch-actions.ts/AiVaultSessionDropLayer.tsx confirmed present on unmodified main too, out of scope here)
• oxlint on the changed file — clean

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: fc3c8b1a-ace7-4be2-b7a7-1a1d9bf549d0

📥 Commits

Reviewing files that changed from the base of the PR and between 6c9be22 and 630506e.

📒 Files selected for processing (6)

• src/renderer/src/components/settings/browser-search.ts
• src/renderer/src/i18n/locales/en.json
• src/renderer/src/i18n/locales/es.json
• src/renderer/src/i18n/locales/ja.json
• src/renderer/src/i18n/locales/ko.json
• src/renderer/src/i18n/locales/zh.json

---

📝 Walkthrough

Walkthrough

The browser settings description now uses translate(...) with the platform-specific shortcut label as value0. A new translation entry was added for English, Spanish, Japanese, Korean, and Chinese locale files, describing built-in browser handling for links from the terminal, Markdown, and editor while directing the interpolated shortcut action to the system browser.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description covers summary and testing, but it omits required Screenshots, AI Review Report, Security Audit, and Notes sections.	Add the missing template sections, including screenshots or no visual change, AI review details, a security audit summary, and notes.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: localizing the Link Routing settings description.
Linked Issues check	✅ Passed	The change localizes the Link Routing description via translate() and adds the catalog key, matching issue #9652.
Out of Scope Changes check	✅ Passed	The changes are limited to the Link Routing description code and related locale entries, which are directly in scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[nwparker]

Thank you for this, @Chang-Jin-Lee — and welcome. Your diagnosis was exactly right: getBrowserLinkRoutingDescription() was a bare template literal, the codemod skipped it because of the interpolated shortcut, and {{value0}} is the correct placeholder convention (it's literally what localize-renderer-strings.mjs emits — value${index}). You and #9444 arrived at the same approach independently.

We're consolidating this cluster on #9444, for two reasons:

1. Translations. fix(i18n): localize the Link Routing description in browser settings #9444 ships real es/ja/ko/zh copy. This PR follows the documented sync:localization-catalog behavior of propagating the English fallback into the other catalogs — which is legitimately the repo's convention for feature PRs, and you were right to cite it. But since the whole point of this particular fix is that the string renders in English under a non-English UI, leaving the English fallback in es/ja/ko/zh means the reported bug is still visible to the user. This one case needs the translations inline.

2. The catalog key. d0fdcd86b1 is sha1(path + ':' + head) over the untrimmed head text. The codemod runs the candidate through compactText() (replace(/\s+/g, ' ').trim()) before hashing, so the key it would actually generate is 904ce58440 — the trailing space before ${...} is what separates the two. I verified this by re-deriving the hash for existing {{value0}} keys in the catalog: the trimmed head reproduces 29/29 of the decisive samples, the untrimmed head 0.

Worth stressing that this is an easy thing to get wrong and nothing in CI would have told you: verify-localization-catalog.mjs only checks key existence, placeholder consistency, and locale parity — it never recomputes the hash. Your PR passed that gate, as you reported. The key would only have drifted the next time someone re-ran the codemod.

Your {{value0}} choice is the one that shipped, and your independent confirmation of the root cause raised confidence in the fix. Closing in favour of #9444 — please do send more, and thanks for taking the time.