[jakero]

Summary

• Add 10 missing Settings i18n keys to all 18 locale bundles.
• Remove Chinese hardcoded fallbacks from 12 call sites across 4 files.
• Align the new translations with existing locale terminology and style.

Validation

Verified locally on the merged branch (Node scripts, no external tooling):

• Every one of the 90 keys upstream added between v1.3.66 and v1.3.68, and all 34 upstream value changes in that range, survive byte-identical in all 18 bundles.
• The 10 carried-over keys hold the exact translations from this branch, and the 5 keys upstream owns hold upstream's values.
• A per-object duplicate-key scan over all 18 bundles reports none. This matters because the merge combined two different definitions of settings.general.errorReporting and errorReportingDesc into every bundle; JSON.parse silently keeps the last one and check_locales.cjs de-duplicates with a Set, so neither would have surfaced it.
• {{placeholder}} sets match en for all 10 keys in all 18 bundles, and no bundle has an empty value.
• No non-English bundle reuses the en/en-US string for these keys, with one exception below the duplicate threshold: common.edit is "Edit" in id, which is the correct Indonesian word.
• All 292 locale keys referenced by the 4 changed components resolve in all 18 bundles.
• Committed blobs use LF line endings, matching upstream.

npm run typecheck, npm test and node scripts/check_locales.cjs were not re-run locally during these merges (no node_modules available); the checks above are the structural equivalent for the files this PR touches.

Notes

• Related to Missing translations for 94 fallback strings (showing Chinese in UI) #2083. This PR addresses the Settings-related subset and does not close the full 94-key issue.
• Translations were reviewed against existing locale vocabulary; native-speaker review of the longer descriptions is welcome.

[jakero]

Rebased onto upstream/main — this PR was 40 commits behind and GitHub reported it as CONFLICTING. It is now MERGEABLE. (I also corrected the stale numbers in the description above.)

Conflict resolution. All 18 conflicts were in src/locales/*.json, one block per file, with an identical shape in every one: this branch appends common.{clear,done,saved,edit} while upstream appends common.{hide,show} at the same insertion point. Neither side could be discarded, so both key sets are kept. The 5 touched .tsx files merged automatically, and the result is purely additive — no upstream change is reverted.

What this means for review. The diff is still the same 23 files (18 locale bundles + 5 components). The 40 upstream commits appear in history but not in the diff. One spot worth a glance: the two key sets now sit adjacent in the common object of each bundle, and ordering there is not alphabetical.

Ready for review.

[jakero]

Conflict resolution against upstream/main (v1.3.66)

This supersedes my 2026-09-30 comment above, which described an earlier attempt. The branch now merges upstream/main, which had moved 7 commits past the previous merge base (v1.3.63).

All 18 conflicts were in src/locales/*.json: one block per file, same shape in every one.

Root cause. Both sides appended keys to the end of the settings.general object, at the same insertion point. Git's line-based 3-way merge treats two competing insertions at one anchor as a conflict regardless of whether the key sets overlap; removing the overlapping keys does not clear it.

Resolution: upstream wins any overlap. 22 keys across the two sides, 20 kept:

Keys	Outcome
accountLevelRefresh* (6), errorReporting (+Desc), common.done/saved/edit, appPath.missing.scanEmptyGeneric (12)	kept from this branch
floatingCard* (7), themeColorOled, codexPreserveExternalBridge (+Desc) (10)	kept from upstream
codexAutoRestoreTakeoverOnLaunch (+Desc)	dropped; upstream owns these
common.clear	dropped; would be a duplicate key

Why the two codexAutoRestoreTakeoverOnLaunch keys were dropped. upstream added them in v1.3.66 with different wording, and its text matches the current implementation: maintain_local_access_profile returns early when a profile is not Cockpit-owned and only rewrites the provider fields it manages, which is what "still managed by Cockpit / keep manually edited connections" describes. This PR's copy was lifted from the Chinese fallback string being deleted, and claimed it preserves "1M context without manual switching"; the restore path does no such thing.

Why common.clear was dropped. common.clear did not exist in the merge base: this branch and upstream each added it independently, so the auto-merged common object held it twice. Both copies are "Clear", so JSON.parse silently keeps the last one and nothing crashes, but it is an invalid duplicate and check_locales.cjs would not have caught it. The branch copy is dropped, so common.clear appears exactly once per bundle.

Also. upstream had already removed the Chinese fallback from SettingsCodexPlatformPanel.tsx, so 2 of the original 16 call sites needed no change. The diff is 22 files (+250/-42), not 23.

Nothing from upstream is reverted. All 181 keys added between v1.3.63 and v1.3.66 survive byte-identical in all 18 bundles, and the 7 keys deleted in that range are not reintroduced.

[jakero]

Follow-up merges: v1.3.67 and v1.3.68

This supersedes my previous comment above, which covered the v1.3.66 merge. Since then upstream/main moved twice (v1.3.67, v1.3.68) and this branch now merges it cleanly with no reported conflict.

The v1.3.67 merge produced a duplicate key in all 18 bundles, and nothing flagged it.

upstream added settings.general.errorReporting and errorReportingDesc in v1.3.67, but placed them earlier in the settings.general object than this branch did. Because the two insertions landed at different anchors, git's line-based merge combined them instead of reporting a conflict, so every bundle ended up with both definitions:

"errorReporting": "Diagnostics",                     // upstream, earlier
...
"errorReporting": "Telemetry diagnostics",           // this branch, later

JSON.parse keeps the last definition, so this branch's wording would have won at runtime, and that wording came from the Chinese fallback string this PR deletes. check_locales.cjs did not catch it either: it collects keys into a Set, which hides duplicates by construction. Only a per-object duplicate-key scan surfaces it. The branch-side copies were dropped and upstream's kept.

Worth noting that upstream also removed the Chinese fallback from those same two t() call sites in v1.3.67, so those two are no longer part of this PR.

Final split against upstream/main (v1.3.68).

Keys	Outcome
common.done/saved/edit, settings.general.accountLevelRefresh{Title,Desc,SummaryActive,Summary,Inherit,Disabled}, appPath.missing.scanEmptyGeneric (10)	kept from this branch
common.clear, codexAutoRestoreTakeoverOnLaunch (+Desc), errorReporting (+Desc) (5)	upstream owns these; branch copies dropped

Nothing from upstream is reverted. All 90 keys added between v1.3.66 and v1.3.68 and all 34 upstream value changes in that range survive byte-identical in all 18 bundles, and the 7 keys upstream deleted earlier (codex.tempLogin.intercept, codex.tempLogin.authUrl) are not reintroduced.

Scope check. Across all of src/, 1660 t('key', <CJK>) fallbacks remain, of which 87 reference a key missing from every bundle. All 87 sit outside the 4 files this PR touches, so this PR leaves no missing-key gaps in its own scope; the rest belongs to the remaining part of #2083.

Two of the keys added here are also referenced from files outside this diff (App.tsx, CodexWakeupContent.tsx, ClaudeAccountsPage.tsx), which were previously showing the raw key or a Chinese fallback.