b22df1381e
rega measured the Arabic packet (row 83) and found page 8 still English. dx-shepherd's rule, which this follows exactly: NEVER machine-translate Scripture — use a published public-domain translation per locale, cited with its name (END-DXS-MK5GO). ar Arabic Van Dyck Bible ru Russian Synodal Bible es Reina Valera 1909 de German Luther Bible 1912 fr French Ostervald Bible Fetched from bible.helloao.org, which ships licenceUrl + website + sha256 per translation and points at ebible.org's own licence pages. Full provenance — translation id, name, licence URL, sha256 — is recorded in data/people-groups/scripture-sources.json, because a credit line on the page can carry a NAME but not a verifiable source, and the two are different claims. ★ VERSE NUMBERING VERIFIED AGAINST THE ENGLISH, not assumed. All five extract exactly verses 1-20 of 43 in the chapter; verse 1 matches the WEB's "they came to the other side of the sea, into the country of the Gadarenes" and verse 20 ends at "Decapolis ... everyone marveled". Lengths land within 1,689-2,399 chars against the English 2,141, which is the spread you would expect across languages rather than a truncation. The English passage carries no verse numbers, so these are joined as continuous prose the same way. ⚠ AND I DID NOT WRITE ANY OF IT FROM MEMORY. Scripture reproduced from recall is machine translation with extra confidence — the same failure the rule forbids, one step removed. Every character came from the API and was checked against the English before storing. hi/zh/pt/it/ro STAY ENGLISH and stay in DECLARED_ABSENT, which is now narrowed rather than deleted: PD candidates exist (Hindi 1851 Serampore-lineage, Chinese Union Version 1919, Almeida 1819, Diodati 1649, Cornilescu 1924) but their licence status varies by jurisdiction and I could not confirm it. The entry shrinks one locale at a time as each is cited. VERIFIED: check:packet-strings-parity PASS, and the ar and de packets both render 9 sheets PASS with the passage and its credit on page 8. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| vendor/cldr | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.