Chore/936 i18n parity check#957
Open
Topmatrixmor2014 wants to merge 8 commits into
Open
Conversation
…tion.ts - Moved useTransactionPolling hook into useTransaction.ts so all transaction status tracking lives in a single module - Added architectural comment establishing single-implementation convention - Updated TransactionStatus.tsx to import from useTransaction.ts - Deleted useTransactionPolling.ts (duplicate file) - Downgraded jsdom from 29.0.1 to 25.0.1 to fix ESM compatibility issue blocking all tests
… PromiseRejectionEvent Fix duplicate routes in App.tsx (broken closing tag blocking lint/format/build). Fix useTransactionHistory.test.ts vi.mock hoisting with vi.hoisted(). Fix unhandledRejections.test.ts with PromiseRejectionEvent polyfill for jsdom.
Run prettier --write to fix code style issues flagged by format:check.
The main branch merge changed useTransactionHistory.ts to use fetchRef.current and added filterKey dep to debounce. Updated loading test to use sync act for timer + async act for microtask flush. Updated cache test to expect re-fetch on options change (now correct behavior).
Add a validation script (scripts/check-i18n-parity.mjs) that flattens locale JSON keys and ensures all locale files (es.json, fr.json, pt.json) contain every key present in en.json (the source of truth). This commit also fixes existing drift in locale files and integrates the check into: the CI pipeline (blocking step), the lint-staged pre-commit hook, and the CONTRIBUTING.md documentation. Closes Favourorg#936
The check-i18n-parity.mjs script uses process.exit() and process.argv, which are Node.js globals. The ESLint flat config only included globals.browser and globals.es2020, causing two no-undef errors in CI. Added a config override for scripts/*.mjs files with globals.node.
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.
Description
Four locale files exist with no CI step (found in the reviewed workflows) diffing their key sets against each other. i18next's default behavior on a missing key is typically a silent fallback (to the key itself or the fallback language) rather than a build failure, meaning a developer adding a new UI string, updating en.json, and forgetting the other three locales produces no error anywhere in the pipeline — the regression is only discoverable by a native speaker of the affected language actually using the app and noticing an English (or raw key) string where a translation should be, which for a project explicitly targeting "emerging markets" users (per the README's stated mission) undermines a core part of the product's value proposition without any safety net catching it.
Tasks
Write a small script (scripts/check-i18n-parity.mjs or similar, following the existing pattern of scripts/check-wasm-size.mjs) that loads all locale JSON files, flattens their keys, and asserts every locale has exactly the same key set as en.json (the presumed source of truth), failing with a clear diff of missing/extra keys per locale otherwise.
Wire this script into .github/workflows/ci.yml as a blocking step, and into .lintstagedrc.js/pre-commit if fast enough to run on every commit touching frontend/src/i18n/.
Run it once against current state and fix any drift already present before making it blocking.
Document the "adding a new translation key" workflow in CONTRIBUTING.md's existing "Adding a New Language" section.
Acceptance Criteria
CI fails on a PR that adds a key to en.json without adding the corresponding key to es.json/fr.json/pt.json.
All four locale files currently have matching key sets (post-fix), verified by the new script passing on main.
closes #936