af10d727c4
Two pools had ever been checked — eBible and JESUS Film — and the map said "nothing found" for everyone outside them. For 240 people groups that claim was simply untrue: unfoldingWord publishes a released resource in their language and we were not looking. WHAT WAS ADDED. A dated snapshot of the Door43 catalog (stage=prod only) keyed by ISO 639-3, 165 codes across Open Bible Stories, Bible and Aligned Bible. Cached rather than fetched live so the pin table is reproducible offline and does not depend on someone else's uptime; the source URLs travel in the file. stage=prod IS THE WHOLE CARE. Door43 LISTS more languages than it HOSTS, and this repo already recorded that trap — "roster membership is not coverage". Released entries only, and the result reconciles cleanly against what was already known: of 38 languages previously flagged as having Open Bible Stories, 38 are confirmed and 0 contradicted. It also found 11 flagged false that do have a published resource. THE BIGGER HALF WAS INVISIBLE. 116 of the 165 codes have no row in people-group-resources.json at all, so there was no record to hang a link on and their pins stayed "nothing found" no matter what Door43 published. Those codes are now created from the catalog, which is where 213 of the 240 lifted pins come from. COVERAGE: pins carrying a real URL 5,109 -> 5,349 (41.3% -> 43.2%); codes 862 -> 978. Tier 1 now means SOMETHING was found rather than "one of scripture/film", because that is what the colour has to mean once a third pool exists. Tier 2 still means Scripture AND film — a story set does not get promoted into a Bible. OBS IS LABELLED AS STORIES. The chip reads "Bible Stories · Door43", never Scripture: Open Bible Stories is 50 illustrated narratives drawn from the canon, and telling a reader they have a translation when they have a story set is the one lie this map cannot afford. 2-letter and region-suffixed tags are DROPPED rather than guessed into 639-3 — a wrong language match ships a real link to the wrong people. Verified on the served tree: the Kir people group (Mandeali, mjl) previously showed nothing and now renders a real anchor to git.door43.org/OBS-TLF/mjl_obs, which answers 200. The existing pin probe still passes 12,379 rendered with both Han Chinese links at 200, so the new pool added coverage without disturbing the old. |
||
|---|---|---|
| .. | ||
| external-bundles | ||
| 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.