# Wikitrivia is a timeline game that sources its cards from Wikidata

> Wikitrivia is a year based trivia card game built from Wikimedia data, with the content generated from Wikidata Query Service snapshots into deck JSON files, a Next.js front end exported as a static site, and a correction policy that sends wrong answers back to Wikidata rather than fixing them locally. The whole toolchain runs on Bun.

**tom-james-watson/wikitrivia** — Wikidata as a trivia card game.

- Repository: https://github.com/tom-james-watson/wikitrivia
- Website: https://wikitrivia.tomjwatson.com
- Stars: 600 · Forks: 106
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tom-james-watson-wikitrivia

## A timeline game built on structured data

Wikitrivia is a year based timeline trivia game built from Wikimedia data, and the live app is hosted at the project's own domain. The framing of a timeline is the interesting design choice, because it constrains what a card can be. A question is anchored to a year, and the answer is a fact that Wikidata records about something in that year, which means the game is a rendering of a query rather than a set of hand written questions. That has an obvious appeal, since the pool of possible cards is as large as the knowledge base, and an obvious weakness, since a card is only as good as the query that produced it. The repository is a TypeScript project with a pages directory, components, styles, a lib directory for shared logic, a types directory, a tests directory and a public directory, and the primary language is recorded as TypeScript. The package is marked private with a version of 0.1.0, which tells you the project is not packaged for consumption but built and deployed as a site.

## Snapshots in, deck JSON out

The content pipeline is the heart of the project and it is described in one sentence. Game content comes from Wikidata Query Service snapshots kept in the content queries directory, and that content is built into deck JSON under the public decks directory, with the tooling documented separately in a readme in the content folder. The scripts in the package manifest show the shape of the workflow. There is a script to build the cards and a script to print the deck tree, which suggests the decks form a hierarchy rather than a flat list, and there are two scripts for working with the query service, one that lists the available queries and one that runs them.

```bash
bun run sparql:list
```

```bash
bun run decks:build
```

The use of snapshots is the decision that makes this approachable. A build that hits the live query service would be at the mercy of its availability and its response times, and a query can return different results as the underlying data changes. Snapshotting the queries and building decks from the snapshots means the site build is deterministic and the live site is not a proxy for a public endpoint. The cost is that the content has a refresh interval, and the corrections policy depends on that interval.

## One environment variable, and it is about manners

Before running any script that contacts the Wikimedia APIs, the README asks you to copy the example environment file and set a single variable, and the example file contains exactly one line, a contact email placeholder. The purpose is stated plainly. The address is used in API requests to identify yourself to Wikimedia. That is a small detail with a large etiquette dimension, because the Wikimedia APIs are shared public infrastructure and a request that identifies its caller lets the operators contact you if something is wrong. It is also the kind of step that a developer cloning the project to try it will skip, and then wonder why a request is rejected.

```bash
cp .env.example .env
```

```bash
WIKITRIVIA_CONTACT_EMAIL=your-email@example.com
```

The project is a good example of the practice that open source projects built on public APIs should follow. There is no key to obtain, no account to create and no terms to click, just an address and the expectation that requests are attributable.

## A static export rather than a running server

The front end is Next.js on React 19, and the deployment shape is a static export. The development server runs locally on port 3000, the build produces a site, and the built output directory is served by a static file server rather than by a Node process.

```bash
bun run dev
```

```bash
bun run build
```

```bash
bun run start
```

That last command serves the out directory, which confirms the export is complete and self contained. For a trivia game this is the right shape, since the site is read heavy, the data is in the deck files rather than behind an API, and a static deployment on a CDN costs almost nothing. The styling is worth a note, because it is not the usual Tailwind. The dependencies include the vanilla extract toolchain with a Next plugin, with recipes and a sprinkles package, which is a zero runtime CSS-in-TypeScript approach that generates atomic class names at build time. The other runtime dependencies are small and specific, the class names helper, the motion library for animation, and a GitHub button component, which is presumably for the footer. A trivia game is a light application and the dependency list reflects that.

## A toolchain built around a single check command

The scripts are organised around one composite command called agent check, which runs the typecheck, the lint and the format in sequence, and the individual pieces are worth reading because they show the toolchain choices. Linting runs the TypeScript compiler and then oxlint, so a type error and a lint error are reported by one command. Formatting is handled by oxfmt, with a configuration file, a check mode, and the repository's own ignore files passed in so that generated and vendored paths are left alone. The test suite runs on Bun's own test runner, and the typecheck is the compiler in no emit mode. The tree also shows that the project is set up for several coding agents at once, with directories for agent configuration, a Claude directory, a Codex directory, a Zed directory, an AGENTS.md file and a skills lock file. That is a strong signal about how the project is maintained, and the single agent check command is the natural result, since one command has to be enough for a human and for a tool.

## Wrong answers are fixed in Wikidata, not in the game

The most interesting policy in the README is the answer to a question most projects handle with a contact form. If you find a card with incorrect data, the instruction is to fix the underlying Wikidata item directly on Wikidata, and it will then be synced back into the game the next time the decks are updated. The project is therefore not a fork of the data with local patches, it is a view over a shared source, and the update cycle in the content pipeline is the mechanism that makes corrections appear. Two consequences follow. A player who knows that a card is wrong is asked to become an editor of a public knowledge base, which is a reasonable division of labour when the cards are derived from it. And a card can still be wrong for a reason the item is not, because the query behind it may be selecting the wrong fact, in which case the fix is in the content tooling rather than on Wikidata. The FAQ does not discuss that second case, and it is the one a maintainer will hit first.

## Conclusion

Wikitrivia earns its place as a reference for building a data product on a public knowledge base, because the content pipeline is separated from the game, the snapshot approach means the site does not depend on the query service being up, and the correction policy keeps a single source of truth rather than accumulating local edits that drift. It is a poor choice if you want a game with hand written trivia, since the cards are generated from structured data and the errors are data errors, and a poor choice if you cannot host a static site with a content rebuild step, since the decks are regenerated rather than edited. Verify three things before you copy the approach: that you set a contact email before running anything that queries Wikimedia, since that is the identification the API requests are expected to carry, that your snapshot refresh interval matches how often the underlying data changes, and that the deck structure you produce is answerable, since a generated card is only as good as the query behind it. The licence is MIT, the last push was on 2026-09-06, and the repository publishes no GitHub releases.

## FAQ

### Where does Wikitrivia get its data?

The data is sourced from Wikidata and Wikipedia. Game content comes from Wikidata Query Service snapshots in the content queries directory, which are built into deck JSON files under the public decks directory, and the tooling for that is documented in the content readme.

### How do I run Wikitrivia locally?

Install the dependencies with Bun, copy the .env.example file to .env and set your contact email, then run bun run dev and visit localhost:3000. The build uses bun run build and the built out directory is served with bun run start.

### I found a card with wrong data, what should I do?

The README says to fix the underlying Wikidata item directly on Wikidata, and it will be synced back into the game the next time the decks are updated, so the game is a view over a shared source rather than a local copy.

### What checks does Wikitrivia have for code quality?

There is a composite agent check script that runs the typecheck, the lint and the format in sequence. Linting runs the TypeScript compiler and oxlint, formatting is handled by oxfmt with a check mode, and the test suite runs on Bun's test runner.

## Sources

- [Issues](https://github.com/tom-james-watson/wikitrivia/issues)
- [License: MIT](https://github.com/tom-james-watson/wikitrivia/blob/master/LICENSE)
- [Project website](https://wikitrivia.tomjwatson.com)
- [README](https://github.com/tom-james-watson/wikitrivia/blob/master/README.md)
- [tom-james-watson/wikitrivia on GitHub](https://github.com/tom-james-watson/wikitrivia)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tom-james-watson-wikitrivia