Run l10n string extractor on pre-commit
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 233
- Forks
- 61
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 82
Description
Follow up to https://github.com/mdn/fred/pull/452#pullrequestreview-3931216678
A naive implementation (run npm run l10n && git add l10n/template.ftl) has its issues, I tested it locally with:
- add string to components/a.js
- add string to components/b.js
- stage a.js
- commit
- new strings from both a and b end up in template.ftl
The extractor script could be updated to take a list of files to operate on, however that doesn't currently work either because it doesn't read template.ftl but regenerates and overwrites it in a deterministic way - running on only a few files would mean only a few strings would end up in the output.
Perhaps the easiest approach is to run it as a rspack plugin on every build - like we do already with the custom element types file generation - and leave it to the developer to commit whichever parts of it are relevant in a multi-commit clean-stage messy-tree workflow?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the implementation behind npm run l10n and the existing custom element types generation used in the rspack build. Determine a workflow that preserves the complete deterministic l10n/template.ftl while handling staged and unstaged files; done means the process updates the template without dropping strings from other components.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- build-system, localization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100