test(frontend): add locale-completeness coverage for /learn content - #199
Merged
Conversation
The four existing locale-completeness tests (persian/japanese/thai/chinese) all assert against lib/i18n/locales/*, the UI-chrome dictionary — none of them touch constants/learn-content/*.constants.ts, the actual /learn article prose. A manual audit found the content clean today, but nothing caught a future regression, and ar/fr/hi/ru had no locale-specific translation test of any kind. Adds one parameterized test covering all 13 locales: key/section/FAQ parity with English, placeholder parity, and an untranslated-English-fallback check with its own documented allow-list. Running it against real content surfaced 3 genuine judgment calls, resolved and documented rather than silently allowed: - "Orchestration" unchanged in French is correct — it's the same spelling in both languages (the word entered English from French). - "Routing" unchanged in German/Italian eyebrows is a common tech loanword in both languages, not an obvious miss. - "best of N" unchanged in an Italian SEO keyword is deliberate — it's the term a non-English searcher would actually type. All three are commented in the allow-list for a native speaker to override. Knowledge delta: rules/20 now points at this test so it isn't found only by reading the file list. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Resolves the only real conflict, package-lock.json, by taking main's version — this branch's own package.json is unaffected by main's NestJS 12 upgrade, so nothing to reconcile beyond the lockfile. The new learn-content-locale-completeness.test.ts (36 tests) passes unchanged against merged main. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to the AdSense remediation audit (PR #198). That audit found
/learncontent clean across all 13 locales, but flagged a real gap: thefour existing locale-completeness tests (
persian-locale-completeness,japanese-completeness,thai-completeness,chinese-completeness) allassert against the general UI dictionary — none of them touch the actual
/learnarticle content, and ar, fr, hi, ru had no locale-specifictranslation test of any kind.
learn-content-locale-completeness.test.ts: one parameterized testacross all 13 locales checking key/section/FAQ/keyword parity with
English, placeholder parity, and untranslated-English-fallback detection.
rules/20-i18n-and-user-facing-messages.mdnow lists it, so the nextperson adding a long-form content cluster (the rule calls out
public-comparison-content/as the next candidate) knows the UI-dictionarytests won't catch it.
Release notes
New automated test protects the
/learnexplainer content across all 13languages from silently regressing to English or losing sections in a future
edit. No product behavior changes.
What the test actually found
Running it for the first time surfaced 3 real cases where a locale kept an
English/shared string — each one investigated and resolved as a documented
judgment call, not silently allowed:
All three are in the test's allow-list with a comment explaining the
reasoning and an explicit note inviting a native speaker to override if they
disagree — I did not make an irreversible call on translation quality
without saying so.
Test plan
npm run typecheck— 0 errorsnpm run lint— 0 errors (4 pre-existing warnings, unrelated)npm test(full suite) — green; 1 pre-existing flaky timeout(
smart-router-add-entry-form), confirmed unrelated by passing in isolationnpm run build— succeedsnpm run knowledge:verify/knowledge:coverage/audit:check— OK🤖 Generated with Claude Code