Skip to content

i18n: no coverage gate for the locales a deployment adds after zh-CN #102

Description

@os-warren

Recorded while landing #18 (claude/issue-18-i18n-bundles). Not a defect today — a shape the current gate is one locale away from needing.

test/i18n-coverage.test.ts compares the derived key set against zh-CN by name:

const TARGET_LOCALE = 'zh-CN';
const chineseKeys = new Set(bundleKeys((dulyChinese as Rec)['zh-CN']));

and separately asserts that the bundles cover exactly i18n.supportedLocales. So adding ja-JP to supportedLocales plus a ja-JP.ts file would be caught by the locale-set assertion — but once the file exists, nothing checks its key coverage. A ja-JP bundle carrying ten of the 231 keys would pass every test in the file: the two directions are only ever run against zh-CN.

The fix is small and mechanical — iterate the non-source locales in dulyTranslations rather than naming one — and it is deliberately not done on #18, whose scope is the first Chinese deployment. It is filed rather than done so it is a decision on the record instead of a surprise for whoever adds the third locale.

Adjacent, same file, same shape: templateGaps() already iterates supportedLocales generically, so the email-template half of the gate does not have this problem. Only the bundle half does.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions