fix(i18n): show English Memory settings labels instead of Chinese fallback

[craigamcw]

Problem

When the app language resolves to English, several Memory settings labels still render in Chinese — e.g. 运行时配置 and 默认继承当前激活的 API 配置。这里主要调节导航深度、embedding 和落盘目录。.

Root cause: SettingsMemory.tsx calls t('memory.xxx', '<Chinese>') for ~37 keys, passing the Chinese string as i18next's default value (2nd arg). Those memory.* keys were never added to en.json (or zh.json), so i18next falls back to the inline Chinese for every language. The keys exist nowhere, so even zh was relying on the inline defaults.

This is the i18n anti-pattern the project's own src/renderer/i18n/README.md warns against ("避免硬编码 — 所有用户可见的文本都应该通过 t() 函数").

Fix

• Add the missing memory.* keys to en.json (proper English) and zh.json (the strings that were previously hardcoded as defaults). The two locale key sets stay in sync, as the i18n README requires.
• Drop the inline Chinese t() default arguments in SettingsMemory.tsx so the source uses t('key') only, matching the rest of the codebase. This also removes the latent trap where any future missing key silently reintroduces Chinese.
• Remove dead Chinese fallbacks in SettingsPanel.tsx (settings.remote / settings.remoteDesc already existed in en.json, so English was already correct there — the inline Chinese was just redundant).
• Localize the default config-set names (默认方案 / 配置方案 N) in useApiConfigState.ts via the i18n instance + two new api.* keys, so a fresh English install no longer shows a Chinese profile name.

Intentionally not touched: the 中文 native-language label in SettingsGeneral.tsx (correct as-is) and Chinese code comments (not user-visible).

Verification

• tsc --noEmit — passes
• eslint src on the changed files — 0 errors (2 pre-existing unrelated warnings)
• prettier --check — clean
• Renderer/config vitest suite — 89 tests pass (incl. the config-set builders and SettingsPanel entry tests)
• Script check: all 123 i18n keys referenced by the changed files now resolve in both en.json and zh.json; the memory and api namespace key sets match between locales.

No behavior change for Chinese users (same strings, now sourced from zh.json); English users now get English.

[github-actions]

Review mode: initial

Findings

• [Minor] Potential i18n initialization timing risk in useApiConfigState.ts:434. The exported function buildApiConfigSets uses i18n.t() directly via module-level import. Although currently called only from within React component lifecycle (reducer initializer), if called before i18n is initialized (e.g., during module evaluation in tests or future refactors), it could throw or return a missing-key fallback. Consider passing the t function as a parameter to make the dependency explicit and safe for any caller.

  // Suggested approach: accept t as parameter
  export function buildApiConfigSets(
    options: BuildApiConfigSetsOptions,
    t: (key: string, options?: Record<string, unknown>) => string // pass t from useTranslation hook or i18n.t
  ): ApiConfigSet[] { ... }

Summary

No blockers or regressions. The change correctly moves hardcoded Chinese default strings into en.json and zh.json, eliminating the i18n anti-pattern where the Chinese string was used as the fallback for all languages. All keys referenced in the changed source files (SettingsMemory.tsx, SettingsPanel.tsx, useApiConfigState.ts) have been verified to exist in both locale files. The diff is clean and well-scoped. The risk described above is minor and exists only under hypothetical non-React usage; the current code works correctly.

Testing

Not run (automation). The PR states 89 tests pass. No new tests were added for the i18n key coverage, which is acceptable for a pure i18n refactor.

Open Cowork Bot