45354c95ec
A sign language cannot be served by a text translation at all. eBible is a text pool, so its silence for a Deaf group describes OUR SEARCH, not their need — and the sheet was reporting it as "Scripture · none found" exactly as it does for a spoken language. That is the map telling a true-sounding thing that misleads. Sign languages are now flagged in the pin build and the sheet says so: what counts for them is Scripture FILMED in that sign language, and the text pool was never the right place to look. Counts are computed, not typed — 150 sign languages on the map covering 84,159,050 people, and the copy reads "none yet has both" only while that is true, since it is generated from the same pins the layer draws. THE SCALE: 234 pins on 150 sign languages, 183 of them with nothing found, 0 with both a film and a text Scripture. 13 have a JESUS Film through Arclight and 1 has Open Bible Stories through Door43; everything else is empty. ★ A NOTE LEFT IN THE BUILD FOR WHOEVER FILLS THIS GAP. The largest producer of sign-language Bible content by a wide margin is the Watchtower/JW organisation, which is excluded by standing rule — added canon. Anyone researching this will meet jw.org first and it will look like the obvious answer. The legitimate partners are the Deaf Bible Society and DOOR International, and both need credentials this build does not have: deafbible.com is a key-gated app, doorinternational.org answers 403. sign.bible is NOT a source — it is a parked domain listed for sale, which a status-code check would have happily accepted as live. No sign-language resource is added here, because none could be verified. What changed is that the map stops implying the absence was measured against the right pool. Verified on the served tree with a negative control: the note renders for Deaf Nicaraguan (Nicaraguan Sign Language, ncs) and does NOT render for German, so it discriminates rather than always firing. The rendered counts match the build's own tally exactly. Pins, deep-link, filter, gap-list and language-naming probes all still pass. |
||
|---|---|---|
| .. | ||
| 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.