Scoping thoughts - Switching site copy to British English spelling

[Username-Matilda]

I asked Claude for their thoughts on what correcting the website to use British spelling would look like and to write this issue.

For context from the exec side: British English is the deliberate house style for the org. This has been an exec team choice for a while but hasn't been clearly communicated. This issue is to scope and plan the correction. I'm not asking for this to be high prio, but it should get scheduled and done.

---

Size of the job. A scan of the repo for common US spellings (organize, prioritize, analyze, behavior, center, defense, etc.) touches roughly 144 files across src/posts/ (109 English posts), src/routes/, src/lib/, and the message catalogue. The "organiz-" family alone appears 216 times in the posts. So this is a large but very mechanical diff — the risk isn't volume, it's the exceptions below.

The l10n pipeline: a timing consideration, not a blocker. English content is the canonical source for the machine-translation pipeline scripts/l10n/, see docs/L10N.md), and a mass respelling would normally mark every page as changed and trigger re-translation. However: (a) as of now, main is English-only (locales: ['en'] in project.inlang/default-settings.js), so a respelling merged before locales go live costs
nothing — a strong argument for doing this sooner rather than later; (b) even with locales live, a full re-translation sits under the CI spend cap ($0.50), so the concern is less money than churn — regenerating already-reviewed translations is a quality risk; and (c) if needed, re-translation can be skipped entirely by re-committing the existing cache entries after the respelling (the freshness check is by git commit date), which is defensible since a US→GB spelling change wouldn't alter the translated output anyway. pnpm l10n --dryRun verifies the resulting work plan before anything runs.

What must not be respelled

1. URL slugs, route paths, and anchors. Several routes use US spelling in their slugs: /organization, /organizing-a-protest, /local-organizing (plus anchors like #letter-to-the-editor-writing-workshops style fragments). Renaming these means adding redirects (_redirects) and breaks any external links, printed materials, and social posts pointing at them. Keeping US-spelled URLs for now is acceptable if renaming is a significant hurdle — so the recommended v1 scope is prose only, URLs untouched. Slug renames can be a separate follow-up issue with a redirect plan if we ever want them.
2. External URLs — links to third-party pages (e.g. news articles with "organization" in the URL) must never change.
3. Direct quotations — quoted statements from people, papers, and organisations keep their original spelling.
4. Proper nouns — "World Health Organization", "Center for AI Safety", legal entity names in legal.md, etc.
5. Code — variable names, CSS classes, frontmatter keys, config. Only human-visible prose changes.

Recommended approach [note: this is Claude's judgment, not Matilda's - there may be better approaches that are already obvious to you, ofc]

1. Dictionary-driven, human-approved. Use a US→GB substitution tool (e.g. Vale with a substitution style, or a script over a US→GB wordlist) that flags candidates for a human to accept, rather than blind replacement — that's how the URL/quote/proper-noun cases get caught. Restrict it to markdown prose in src/posts/ and visible strings in Svelte components and messages/.
2. Batch the PRs. e.g. posts A–M, posts N–Z, then components/messages. A single 144-file diff is unreviewable; three or four ~50-file diffs are fine. This also spreads the l10n re-translation cost.
3. Verify mechanically after each batch. The repo's existing guardrails cover most of the risk: pnpm check, pnpm lint, pnpm test, and a full pnpm build. A grep for changed strings inside ](...) and href="..." before committing catches accidental link edits.
4. Lock it in with CI. Add an en-GB spellchecker (cspell or Vale with a British dictionary, with an exceptions list for the items above) to CI, and note the house style in CONTRIBUTING/README. Without this, US spelling could drift back with new contributions.
5. Communicate the style decision — since this is exec policy but possibly not yet widely known, a line in the contributor docs plus a note to active writers will prevent the next 100 pages from needing the same cleanup.

Open question for ops - Should the CI spellchecker block merges or just warn, at least initially?