Add an optional en-GB-oxendict spelling gate (default on)#55
Conversation
Generated repositories now enforce en-GB Oxford ("-ize") spelling in
Markdown prose with typos, using the two-layer mechanism stilyagi
introduced in ee77d08a19bc9c1107f30fc2b5bb63ced979fbc4: a generated
typos.toml restores Oxford -ize forms over the en-gb locale, and
scripts/generate_typos_config.py is the single source of truth for its
stems, accepted words, and ignore patterns.
The gate is a new boolean copier option, en_gb_oxendict, defaulting to
true. When enabled the template renders the generator script and the
committed typos.toml, pins the typos version through a Makefile
TYPOS_VERSION variable, and adds a spellcheck target that markdownlint
depends on. Because the generated repository has no Python test
runner, the generator carries the netsuke parse tests' intent in a
--check mode: it tomllib-parses the rendered document (failing fast on
duplicate extend-words keys), asserts the exact entry count, and diffs
the committed file against the generator output. CI runs the gate as a
dedicated step after uv is installed, which required converting ci.yml
to a raw-wrapped Jinja template following the release workflow's
escaping convention. Disabled renders carry no trace of the gate.
Running the gate over rendered output surfaced five genuine spelling
issues in the template documentation (Flavored, signaling, afterward,
parameterisation, and an American citation title), which are corrected
or, for the external citation title, ignored by pattern.
Parent contract tests cover both toggle states, and the rendered
Makefile and CI snapshots are updated accordingly.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 17 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (16)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 21fa0e0aef
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @@ -0,0 +1,1803 @@ | |||
| # typos configuration enforcing en-GB-oxendict (Oxford spelling). | |||
There was a problem hiding this comment.
With _templates_suffix: .jinja, conditional file names need to remain template files for Copier to evaluate the Jinja in the path. This new root file does not end in .jinja, unlike the existing conditional files, so renders get the literal {% if en_gb_oxendict %}typos.toml{% endif %} instead of the typos.toml that make spellcheck expects; default projects then fail the new spelling step as soon as the generator checks for the committed config.
Useful? React with 👍 / 👎.
| $(MDLINT) '**/*.md' | ||
|
|
||
| spellcheck: ## Check typos.toml drift and enforce en-GB-oxendict spelling | ||
| python3 scripts/generate_typos_config.py --check |
There was a problem hiding this comment.
On machines where python3 is older than 3.11 (for example Ubuntu 22.04), this target fails before typos runs because the generator imports tomllib and even declares requires-python = ">=3.12", but the Makefile bypasses the uv shebang by invoking python3 directly. Since the generated docs only require python3, route this through uv/the executable script or explicitly set up a supported Python version for the target.
Useful? React with 👍 / 👎.
1 participant
Summary
Adds an en-GB-oxendict (Oxford "-ize") spelling gate to generated repositories as a new boolean copier option,
en_gb_oxendict, default enabled.Provenance
typos.toml(theen-gblocale corrects American spellings; a generatedextend-wordstable restores Oxford-izeforms) withscripts/generate_typos_config.pyas the single source of truth,typospinned by a MakefileTYPOS_VERSIONvariable (1.48.0, current latest) and run throughuv tool run typos@$(TYPOS_VERSION).enforce-oxendict-spelling, PR netsuke#407) as the base. The generated repository has no Python test runner, so the netsuke parse tests' intent is carried by a--checkmode on the generator itself: ittomllib-parses the rendered document (failing fast on duplicateextend-wordskeys), asserts the exact entry count (len(EXTRA_ACCEPTED_WORDS) + 2*len(STEMS)*len(SUFFIX_PAIRS)= 1766), and unified-diffs the committedtypos.tomlagainst the generator output, exiting non-zero on any mismatch.Toggle semantics
When
en_gb_oxendictis true (the default), generated repositories gain:scripts/generate_typos_config.pyand the committedtypos.toml(generated by actually running the templated generator;--checkconfirms no drift);make spellchecktarget that runs the generator's--checkand thentyposover Markdown files;make markdownlintdepends on it;Spelling (typos)CI step callingmake spellcheck, placed after the existingSetup uvstep souv tool runis available on the runner;AGENTS.md, anddocs/repository-layout.md.When false, renders carry no trace of the gate: no files, no Makefile wiring, no CI step, no documentation. Conditional whole files use conditional path names (including a conditional
scripts/directory); in-file fragments use{% if %}blocks.ci.ymlneeded a conditional step, so it becomesci.yml.jinjawrapped in{% raw %}blocks, following the release workflow's established escaping convention (the only rendered difference with the gate disabled is the raw-block leading/trailing blank line thatrelease.ymlalso has).Validation
actionlintpasses on all rendered workflows.python3 scripts/generate_typos_config.py --checkpasses,typos@1.48.0runs clean over the rendered Markdown,mbake validate Makefilepasses for both toggle states.extend-ignore-repattern.test_lint_targetswhitaker-fallback cases tracked in test_lint_targets whitaker-fallback cases fail on a clean main checkout #53. Rendered Makefile/CI snapshots updated and reviewed.