117467f7e7
Reading the list profile's own screenshot turned up a row for "Undetermined (und)" — 14 people groups — offering two Open Bible Stories links. ISO 639-3 reserves und, mul, mis, zxx and qaa-qtz for exactly the case where the language is NOT known, so a resource attached to one is attached to nothing. Telling 14 groups there is Scripture in their language when the record says the language is undetermined is the single worst thing this map can do, and it took looking at the page to see it. Door43 publishes 4 entries under und; 16 pins sit on a special code. All are now excluded at the index. COVERAGE GOES DOWN, 8,935 -> 8,921 pins with a real URL. That is the right direction: the 14 were false. The same screenshot showed Dogri rendering "Open Bible Stories Open Bible Stories" — two links a reader cannot tell apart. 40 languages carry more than one entry under the same subject, because a language can have more than one independent translation effort. The owner now disambiguates, and ONLY where it is needed: Dogri reads "Open Bible Stories (translationCore-Create-BCS)" and "(OBS-TLF)", while a language with one entry is unchanged. The list profile also gained the pool it predated. It bundles its own resources.json at build time, so Door43 never reached it: 49 languages, 63 links. Checked before writing — 120 of its 862 languages already carry a scripture link and those are exactly the 120 the enriched index has, so nothing there needed correcting, and its curated 862-language scope is this profile's subject rather than staleness. The enrichment is idempotent: it drops what a previous run added before re-adding, or a stale title would survive the index learning to disambiguate. NOT DONE, DELIBERATELY: the 506 zero-reach rows still never match a COUNTRY filter. Arclight carries a primaryCountryId that could attribute them, but the only alpha-2 to alpha-3 mapping in this repo disagrees with itself on 18 countries and cannot resolve 51 of the 168 codes. A wrong attribution would point a real link at the wrong field, so the behaviour is documented in the table meta instead of guessed at. Verified: und/mul/mis/zxx absent from the index, the list renders 49 Door43 anchors where it rendered none, three sampled new links answer 200, and pins, table, deep-link, country and sign-language 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.