A browser extension that spots Wikipedia articles where the subject's parents have their own Wikipedia pages, and gently points it out.
Some people are famous. Some people are famous and their parents were also famous. This tells you which is which.
Open an English Wikipedia article and the extension checks whether the subject has a parent who also has a Wikipedia page. If so, a slim banner appears at the top of the page linking to them. If not — which is most of the time — nothing happens at all.
Try it on Maya Hawke, whose banner links to Ethan Hawke and Uma Thurman.
Every Wikipedia article is linked to a structured record on
Wikidata, Wikimedia's open database. Those records
can list a person's father (property P22) and mother (P25).
It all runs on the public MediaWiki and Wikidata APIs. An article that isn't about a person costs one small request; one with no Wikidata item at all costs none.
To run it from source instead:
Firefox — visit about:debugging → This Firefox → Load Temporary Add-on,
and select manifest.json. Temporary add-ons are removed when Firefox closes.
Chrome — visit chrome://extensions, enable Developer mode, then Load
unpacked and select the project directory.
Requires just, Node, Python 3, and
rsvg-convert (librsvg2-bin on Debian/Ubuntu).
| Recipe | What it does |
|---|---|
just check | Validate the manifest and confirm every file it references exists |
just lint | Run web-ext lint, the same validator addons.mozilla.org runs |
just icons | Re-render the icon PNGs from icons/icon.svg |
just package | Build a store-ready zip in dist/ |
just publish-firefox | Submit that zip to addons.mozilla.org as a listed release |
just publish-chrome | Upload that zip to the Chrome Web Store and submit it for review |
just clean | Remove build output |
just package depends on icons and check, so a build can never ship a PNG
that has drifted from the SVG or a manifest pointing at a missing file.
The two publish recipes need store credentials in the environment. Locally
those can go in a .env file, which the justfile loads and .gitignore
excludes; in CI they come from repository secrets. Real environment variables
take precedence over the file either way.
Hooks are available via pre-commit:
pre-commit install
Syntax, manifest and formatting checks run on commit; the AMO validator runs on push, since it is slow enough to be annoying on every commit.
There is no background script. The content script queries the MediaWiki and
Wikidata APIs directly. This works because both endpoints answer with
Access-Control-Allow-Origin: * (via the origin=* parameter) and Wikipedia's
Content-Security-Policy allowlists wikidata.org — so the requests are legal
page-origin fetches even under Chrome MV3, where content scripts no longer
inherit the extension's host permissions.
The upshot is that one set of files runs unmodified in both Firefox and Chrome,
with no browser/chrome namespace shim and no message passing. If Wikimedia
ever tightens those headers, Chrome will break first and the lookups will need
to move into a background service worker.
The banner is built with DOM methods, not innerHTML. AMO's linter rejects
innerHTML assignment, and using textContent for parent names removes the
need for manual escaping.
Navigation is watched, though Wikipedia does not currently need it.
Article-to-article navigation is a full page load, so the script normally runs
once and the observer never fires. It is there so that a client-side
navigation — from a future Wikipedia change, a gadget, or back/forward through
one — cannot strand one article's banner above another. The observer watches
the <title> node rather than the article body, because any navigation must
update it and it is a single small element. Lookups carry a token so that a
request still in flight when the article changes is discarded rather than
drawing a banner for the page you just left.
Only real people get a banner. Gods and legendary figures have perfectly
good parent claims — Agamemnon's parents are Atreus and Aerope, and both have
articles — so without a check the banner turns up on Greek myth. The subject
must be an instance of human (Q5). Wikidata's judgement is followed rather
than second-guessed, so Homer, tagged both "legendary figure" and human, still
qualifies. The check runs before the parent lookup rather than alongside it:
most articles are not about people, so one small request settles the common
case.
A parent needs a recorded date. Being classed as human is not sufficient on its own. Saint Anne's mother Emerentia, a figure from apocrypha, is an instance of human in Wikidata with eight statements in total and no dates at all — nothing in her item marks her as legendary, so there is no clean signal to filter on. A recorded birth or death date stands in for one. This is a proxy and it fails in one direction: a real but poorly documented parent with no dates is dropped too, and the banner simply doesn't appear.
Deprecated claims are skipped. Wikidata does not delete statements it
considers wrong; it ranks them deprecated and keeps them for reference.
Treating every claim as fact had this extension announcing that Galerius is the
son of Mars, that Konstantin Kuzakov is Stalin's son, and that a living person
is the son of Juan Carlos I — the last a disputed paternity claim Wikidata
explicitly marks as wrong. Normal and preferred ranks are both accepted: within
a single parent property, competing normal-rank claims are usually legitimate
(adoptive alongside biological), so filtering to preferred only would discard
real data.
Claims are fetched one property at a time, on purpose. wbgetclaims only
accepts a single property per call, so father and mother take two requests
rather than one. That looks wasteful next to a single wbgetentities call
until you measure the payloads: a full claim set is 20 KB gzipped for a minor
actor and 190 KB for a country, where the filtered requests are a few hundred
bytes each. They are issued in parallel, so it stays one round trip. Since this
runs on every article anyone opens, the bytes matter more than the request
count.
Nothing is collected, stored, or sent anywhere. The only network requests go to Wikipedia and Wikidata, they carry no cookies or account information, and they exist purely to look up the article you already have open. No tracking, no analytics, no accounts, no settings.
A well-known parent is not evidence that anyone was handed anything. Plenty of people with famous parents built their own careers entirely — hence "maybe". The extension reports a fact and leaves the conclusion to you.
20 commits
6 commits
JavaScript
57.7%
Just
30.2%
CSS
12.1%
A browser extension that spots Wikipedia articles where the subject's parents have their own Wikipedia pages, and gently points it out.
Some people are famous. Some people are famous and their parents were also famous. This tells you which is which.
Open an English Wikipedia article and the extension checks whether the subject has a parent who also has a Wikipedia page. If so, a slim banner appears at the top of the page linking to them. If not — which is most of the time — nothing happens at all.
Try it on Maya Hawke, whose banner links to Ethan Hawke and Uma Thurman.
Every Wikipedia article is linked to a structured record on
Wikidata, Wikimedia's open database. Those records
can list a person's father (property P22) and mother (P25).
It all runs on the public MediaWiki and Wikidata APIs. An article that isn't about a person costs one small request; one with no Wikidata item at all costs none.
To run it from source instead:
Firefox — visit about:debugging → This Firefox → Load Temporary Add-on,
and select manifest.json. Temporary add-ons are removed when Firefox closes.
Chrome — visit chrome://extensions, enable Developer mode, then Load
unpacked and select the project directory.
Requires just, Node, Python 3, and
rsvg-convert (librsvg2-bin on Debian/Ubuntu).
| Recipe | What it does |
|---|---|
just check | Validate the manifest and confirm every file it references exists |
just lint | Run web-ext lint, the same validator addons.mozilla.org runs |
just icons | Re-render the icon PNGs from icons/icon.svg |
just package | Build a store-ready zip in dist/ |
just publish-firefox | Submit that zip to addons.mozilla.org as a listed release |
just publish-chrome | Upload that zip to the Chrome Web Store and submit it for review |
just clean | Remove build output |
just package depends on icons and check, so a build can never ship a PNG
that has drifted from the SVG or a manifest pointing at a missing file.
The two publish recipes need store credentials in the environment. Locally
those can go in a .env file, which the justfile loads and .gitignore
excludes; in CI they come from repository secrets. Real environment variables
take precedence over the file either way.
Hooks are available via pre-commit:
pre-commit install
Syntax, manifest and formatting checks run on commit; the AMO validator runs on push, since it is slow enough to be annoying on every commit.
There is no background script. The content script queries the MediaWiki and
Wikidata APIs directly. This works because both endpoints answer with
Access-Control-Allow-Origin: * (via the origin=* parameter) and Wikipedia's
Content-Security-Policy allowlists wikidata.org — so the requests are legal
page-origin fetches even under Chrome MV3, where content scripts no longer
inherit the extension's host permissions.
The upshot is that one set of files runs unmodified in both Firefox and Chrome,
with no browser/chrome namespace shim and no message passing. If Wikimedia
ever tightens those headers, Chrome will break first and the lookups will need
to move into a background service worker.
The banner is built with DOM methods, not innerHTML. AMO's linter rejects
innerHTML assignment, and using textContent for parent names removes the
need for manual escaping.
Navigation is watched, though Wikipedia does not currently need it.
Article-to-article navigation is a full page load, so the script normally runs
once and the observer never fires. It is there so that a client-side
navigation — from a future Wikipedia change, a gadget, or back/forward through
one — cannot strand one article's banner above another. The observer watches
the <title> node rather than the article body, because any navigation must
update it and it is a single small element. Lookups carry a token so that a
request still in flight when the article changes is discarded rather than
drawing a banner for the page you just left.
Only real people get a banner. Gods and legendary figures have perfectly
good parent claims — Agamemnon's parents are Atreus and Aerope, and both have
articles — so without a check the banner turns up on Greek myth. The subject
must be an instance of human (Q5). Wikidata's judgement is followed rather
than second-guessed, so Homer, tagged both "legendary figure" and human, still
qualifies. The check runs before the parent lookup rather than alongside it:
most articles are not about people, so one small request settles the common
case.
A parent needs a recorded date. Being classed as human is not sufficient on its own. Saint Anne's mother Emerentia, a figure from apocrypha, is an instance of human in Wikidata with eight statements in total and no dates at all — nothing in her item marks her as legendary, so there is no clean signal to filter on. A recorded birth or death date stands in for one. This is a proxy and it fails in one direction: a real but poorly documented parent with no dates is dropped too, and the banner simply doesn't appear.
Deprecated claims are skipped. Wikidata does not delete statements it
considers wrong; it ranks them deprecated and keeps them for reference.
Treating every claim as fact had this extension announcing that Galerius is the
son of Mars, that Konstantin Kuzakov is Stalin's son, and that a living person
is the son of Juan Carlos I — the last a disputed paternity claim Wikidata
explicitly marks as wrong. Normal and preferred ranks are both accepted: within
a single parent property, competing normal-rank claims are usually legitimate
(adoptive alongside biological), so filtering to preferred only would discard
real data.
Claims are fetched one property at a time, on purpose. wbgetclaims only
accepts a single property per call, so father and mother take two requests
rather than one. That looks wasteful next to a single wbgetentities call
until you measure the payloads: a full claim set is 20 KB gzipped for a minor
actor and 190 KB for a country, where the filtered requests are a few hundred
bytes each. They are issued in parallel, so it stays one round trip. Since this
runs on every article anyone opens, the bytes matter more than the request
count.
Nothing is collected, stored, or sent anywhere. The only network requests go to Wikipedia and Wikidata, they carry no cookies or account information, and they exist purely to look up the article you already have open. No tracking, no analytics, no accounts, no settings.
A well-known parent is not evidence that anyone was handed anything. Plenty of people with famous parents built their own careers entirely — hence "maybe". The extension reports a fact and leaves the conclusion to you.
20 commits
6 commits
JavaScript
57.7%
Just
30.2%
CSS
12.1%