[Bug]: Korean UI names the wrong object in workspace/worktree delete and remove copy #11727

Operating system

macOS

Orca version

v1.4.163-rc.1 (audited on main at a2d0e7714)

Details

Short summary: under the Korean UI, Remove workspace reads 워크트리 제거 — "Remove worktree". A workspace and a worktree are different objects removed by different actions, so the button names something other than what it does.

Same defect in the other direction: Open Parent Worktree reads 상위 워크스페이스 열기 ("Open parent workspace").

How to reproduce

1. Settings → Appearance → Language → 한국어.
2. Open a workspace whose SSH host has been removed.
3. Read the button in the reconnect overlay.

Actual: 워크트리 제거 · Expected: 워크스페이스 제거
Key: auto.components.terminal.pane.TerminalSshReconnectOverlay.removeWorkspaceButton

The wider class

Like #9574 did for Simplified Chinese, the anchor bug turned out to be one instance of a pattern. I diffed every en.json leaf against ko.json and checked the call sites — the catalog is structurally complete, the defects are semantic:

The primary row is what I noticed first as a user. 기본 is the word the catalog already uses for default, so the primary-worktree badge on a workspace card reads as a default-branch marker. English keeps them apart — en.json has 11 occurrences of default branch against one primary branch — and Korean merged them.

Why this can't be fixed in the catalog

bootstrap-locale-catalog.mjs translates through the free Google Translate endpoint, one string at a time:

const url = new URL('https://translate.googleapis.com/translate_a/single')
url.searchParams.set('client', 'gtx')
url.searchParams.set('q', text)

No glossary, no context. Remove workspace in isolation is genuinely ambiguous to the translator, so terminology is enforced afterwards by the correction layer in config/scripts/ — that layer just had no rule for this pair. And a value edited directly in ko.json is reverted the next time repair-locale-catalog.mjs runs.

Two things found on the way

1. repair-locale-catalog.mjs can't run at all. repairCatalog passes undefined into repairTranslatedValue for any en.json key the locale catalog hasn't been bootstrapped with yet — 40 today — and crashes:

TypeError: Cannot read properties of undefined (reading 'includes')
    at applyBrandMistranslationFixes (config/scripts/locale-translation-policy.mjs:393:19)
    at repairCatalog (config/scripts/locale-translation-policy.mjs:551:18)

2. Nothing checks a catalog against the policy. CI omits 3 of the 9 lint steps — locale catalog drift ships undetected #10601 added verify:localization-catalog and friends to CI, but they check key parity and coverage, not whether values agree with the glossary. With repair unrunnable, ko.json had drifted 276 leaves behind rules the repo already declares — 작업 공간 → 워크스페이스 has been in LOCALE_PHRASE_FIXES for a while and never applied. A repair --check gate would catch this class; glad to send it separately if it's wanted.

On working-tree — it looks like a third term to unify and shouldn't be. It appears 111 times across four senses: the file-state sense (working tree vs HEAD), the directory sense where git's own vocabulary means a worktree (isMainWorktree is documented as "the repo's main working tree"), literal git stderr matched by regex (cannot remove a locked working tree), and design-doc prose. Only 3 are translatable and all 3 are adjectival — "no working-tree file is available to edit", where what's missing is the file, not the worktree.

Scope — only ko was audited. zh, ja, and es use the same context-free path, so the class is likely present there too; #11505 looks like an instance.

I have a fix ready and will open a PR shortly: phrase-fix rules pinning the vocabulary, the repairCatalog guard, tests, and the terminology contract written into CONTRIBUTING.md. Happy to split the systematic parts into separate issues if you'd rather review them apart.