2 months ago
1881b6c
Davy* fix(i18n): translate remote-library flow strings for zh-CN (#209)
Two user-facing keys were absent from both locales and relied on inline
English `defaultValue`, so zh-CN users saw raw English in the remote
setup wizard heading and the upload progress bar — a mixed-language
screen in a primary onboarding flow.
- Add `setup.openRemoteLibrary` and `progress.uploadingToRemote` to
en.json and zh-CN.json, and drop the `defaultValue` fallbacks at all
three call sites (LibrarySetup, GlobalProgressBar, SongListItem).
- Strengthen locales.test.ts with a remote-flow completeness guard that
scans static `t("literal")` calls and fails when a referenced key
(with or without a defaultValue) is missing from either locale. Plural
keys are resolved through i18next suffixes to avoid false positives.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test(i18n): load remote-flow sources via import.meta.glob, not node:fs
The CI test job runs `tsc --noEmit --project tsconfig.json` before vitest.
The remote-flow completeness guard imported node:fs/node:path/node:url,
which fail that type-check because the app's DOM/bundler tsconfig has no
@types/node — `tsc` exited 1, aborting the step before vitest ran, so
coverage/coverage-summary.json was never produced (the ENOENT symptom).
Load the flow's source files as raw strings through Vite's
import.meta.glob (typed by vite/client) instead, dropping all node
builtins. Adds a file-count assertion so a moved/renamed file fails
loudly rather than shrinking the scan surface.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>Parentcd520d8