Our copy is British, our code is American, and the border runs exactly along the identifier

PubTrivia sells to pubs in Britain, so the copy is written in British English. The code is written in JavaScript, so the code is written in American English. I had never measured where the two meet, so I pulled the text out of <main> on all 72 public pages and counted, then counted the same words in the repository.

The copy side: unanimous

55,466 words across the 72 pages. Every pair came out one-sided:

There is no mixing at all, which is less impressive than it sounds: a one-person site written over a few months in one sitting per page tends to be internally consistent for free. The interesting one is the pair that is not a spelling difference but a grammar rule:

• licence (noun) appears 7 times, in the terms ("you grant us a limited licence to store and display it"), on the QuizXpress comparison ("licences bought from a shop alongside hardware") and on the Kahoot one
• license appears twice, both as a verb or participle: "licensed venues", "owned by or licensed to us"

That is the British rule applied correctly, noun with a c and verb with an s, in a place nobody would check. It is also the kind of detail that goes wrong the moment copy is generated or pasted rather than written.

Compound terms are equally uniform across the 72 pages: wifi 12 times and wi-fi zero, quizmaster 16 and "quiz master" zero, scoresheet 9 and "score sheet" zero, leaderboard 73 and "leader board" zero, "pub quiz" 97 times and "pub-quiz" never. Consistency is not the same as correctness there: the trademark is Wi-Fi with a hyphen, and we spell it the way people type it. Prices are "a month" 20 times, "per month" twice, and "/month" four times, which is the one place the register wobbles.

The code side: the other dialect

The same words in the repository, counting .ts, .tsx and .css under the app:

Flipped, and not because anybody changed their mind. Look at where each side lives and the rule falls out:

American spellings are identifiers. text-center, items-center and justify-center account for nearly all 493 of those. color is a CSS property, a React style key and a Tailwind token. canceled with one l is Stripe's subscription status string, so it appears in a schema comment, in four webhook branches and in the test fixtures, where it is a value in somebody else's API and not a word.

British spellings are prose. The 25 colours are page copy on the question pages and seed data. The centres and behaviours are in comments:

/* ...is a no-op and the existing (non-MoR) behaviour is unchanged. */

So the border is not between files, it is inside them: the same developer writes justify-center on one line and "behaviour" in the comment above it, because one is a name and the other is a sentence.

Some of the American spellings are not negotiable at all, and you can read them in the page source of any page on the site:

• <meta name="theme-color" content="#171717">
• color-scheme: dark in the stylesheet
• "@type":"Organization" in the JSON-LD
• localStorage, Intl.NumberFormat, normalize, every DOM API we touch

A British site cannot spell theme-color any other way. The spec owns the name.

Where it leaks

Exactly one user-visible string in the whole application is spelled American, and it is not one of the forced ones. On the billing page:

const statusLabel = isActive ? 'Pro'
  : isTrial ? (trialAvailable ? 'Trial available' : 'Trial used')
  : 'Canceled'

The status value from Stripe is canceled, correctly, because that is the API's vocabulary. The label is a string somebody typed, and it inherited the API's dialect on the way through. One screen away, the charity fundraisers page tells the same customer that a month of Pro "can be cancelled afterwards".

So a venue owner who cancels can see the word spelled both ways within one session: two ls in the marketing copy, one l in the badge on their own billing page. Nothing is broken. It is just the seam showing.

No test catches it either. We have a copy test that pins the conversion wording and the currency sentences, and it works by regex over specific phrases. There is no dictionary in the pipeline, and there could not easily be one: a spellchecker set to en-GB would light up on several hundred identifiers before it reached a single sentence, which is exactly why this class of mistake survives in a codebase that is otherwise linted to death.

The rule worth writing down, since we were following it without saying so: a name keeps the dialect of whoever defined it, and a sentence keeps yours. The bug is always the string that is a sentence pretending to be a name.

Check it yourself

Open any page under pub-trivia.app/quiz-questions and search for "colour", then view source on the same page and search for "color". Both are there, in the same response, and neither is wrong.