feat(i18n): detect missing and dynamic translation keys#1046
feat(i18n): detect missing and dynamic translation keys#1046danielroe merged 3 commits intonpmx-dev:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
📝 WalkthroughWalkthroughAdds i18n validation tooling and centralises translation label resolution across multiple Vue components. Introduces a CI job "🌐 i18n validation" running on ubuntu-24.04-arm that checks out the repo, sets up Node (latest LTS), installs pnpm, installs root dependencies without running scripts, and runs Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (1)
app/components/Org/MembersPanel.vue (1)
358-359: Minor inconsistency with role label approach.The role filter buttons use
getRoleLabel(), but the role<select>options at lines 476-478 use direct$t()calls. Both approaches work, but consider usinggetRoleLabel()consistently if the goal is to centralise role label management.
|
I also think we might consider auto-pruning unused keys 🙏 |
Good idea, will open a PR for this as well :) |
Add i18n validation to CI
What's this about?
Added a script that checks if all translation keys used in the code actually exist in our locale files. It also flags dynamic keys like $t(someVariable) which can't be statically validated.
Changes
Why bother?
Right now, if someone uses $t('typo.in.key'), nothing breaks during build, it just shows up broken for users.
This catches those issues before they get merged. The CI will fail on:
Long term
As we add more locales, manually checking translations becomes impossible. Better to automate it now than debug weird blank strings in production later 😄