b089f9effb
GRN records the gospel as AUDIO for languages with no writing, which is most of what is left in the gap — and every earlier attempt recorded it as unreachable. globalrecordings.net sits behind a proof-of-work bot shield that challenges even robots.txt; that is an access control and is not worked around. Their own delivery site, 5fish.org, is not shielded, allows what this reads, and resolves by ISO 639-3 directly. First 180 gap codes swept: 74 hold gospel audio, a 41% hit rate, and 147 people groups that had nothing now have the gospel in a form they can receive. Tier 0 falls 2,873 to 2,746. The host NEVER 404s. A nonsense path returns HTTP 200 and a plausible geo-located page, so reading 200 as existence would have marked every code on earth as covered. Existence is read from the page title, and a negative and a positive control run in band on every run — the fetcher aborts if a nonsense code ever reads as a real language. Their robots.txt asks for a ten-second crawl delay, so the sweep is sequential, capped per run and resumable. Do not add concurrency. Three sign languages are deliberately left out. GRN's catalogue is audio; 5fish holding a page titled "Pakistan Sign Language" says they index the language, not that they have signed video. Attaching it told 20 Deaf groups — 11.5 million people — that gospel audio was available to them. Unverified, and for that audience useless. Six places across three surfaces still told the reader GRN answers 403 to everything and had never been searched. That is now false, and a stale caveat misleads exactly as much as a stale number. Also here, because adding a source is what exposed it: the charts profile decided "this group has nothing" a second time, by listing the resource fields by hand. That list went stale every time a source was added — 7 languages once, 23 when Scripture Earth landed — so the chart drew groups as having nothing while the map offered them a working link. It now reads the tier the pin index already computed, and a new gate refuses any surface that re-derives it. The gate was checked against the real pre-fix file, not only a synthetic one. |
||
|---|---|---|
| .. | ||
| external-bundles | ||
| legacy/upg-neighbor | ||
| people-groups | ||
| posters | ||
| tables | ||
| vendor | ||
| README.md | ||
data/ — the bundler's source-of-truth data
The law: data lives here; public/ is generated. Every folder in data/ is copied into the
served web-root by the build (internal/generate-tree.mjs), exactly like the per-profile data in
plugin-designs/*/data/. You should be able to rm -rf public/ and get it all back with bun run build.
| Folder | Served at | What it is |
|---|---|---|
people-groups/ |
/assets/people-groups/ |
People-group datasets (CSV/JSON) the maps read at runtime |
vendor/ |
/assets/vendor/ |
Third-party runtime assets (e.g. table libraries) |
posters/ |
/assets/posters/ |
Rendered poster webp set (heavy pipeline output; poster walls fetch these) |
tables/ |
/assets/tables/ |
The MERGED served table set (its index.json is the merge; per-profile plugin-designs/*/data/tables are build-time sources) |
external-bundles/ |
not served | Prebuilt map IIFEs vendored from sibling projects (not built here); only the optional layouts/ shell mounted them, so the build no longer copies them into public/ |
Don't edit anything under public/ by hand — change it here (or in plugin-designs/*/data/,
layouts/*/assets/) and rebuild.