REGREL. Two library sites rendered RELIGION_FAMILIES values as English in every locale: the Religion legend's rows (useLegendData.js) and the search aggregate that collapses sub-types into their family (useSearch.js). Both now project the LABEL through religionFamilyLabel(), which resolves through the catalogue and keeps English as the last resort. The half worth a gate is the half that did NOT change. A translated value matches nothing — the moment a localized string lands in a filter, a bus payload or an element attribute, the link works in English and fails silently in Arabic. So `key` and `filterKey` stay the canonical family letter, useSearch's key function stays bare getReligionFamily(), and the check asserts all of that as well as the projection. RELIGION_FAMILIES is no longer imported in either file: the label was its only local use, and religionFamilyLabel reads the canonical map internally. ★ A COMMENT IN useSearch.js ARGUED AGAINST THIS FIX, and it was wrong. It read "label = family name so selection can resolve the family letter back (see research-map onGeocoderAggregateResult religion branch)" — presenting an English label as a REQUIREMENT of selection. Measured: onGeocoderAggregateResult does not exist anywhere in this repo (three comments name it, nothing defines it), and selection resolves by value — aggregate() emits `key` and `label` as separate fields, and the consumer reads detail.expectedValue (countries-map.vue:1611). Retracted in place with the measurement, not deleted, because a reader who has seen the old claim needs to know it was tested. check:religion-label-not-value is registered and negative-tested. It executes religionFamilyLabel's REAL source against the SHIPPED ar/ and en/ religion.json rather than a stub, because religion.js imports tStatic through an i18n index that calls import.meta.glob and cannot load in plain Node. Under ar the label is المسيحية while RELIGION_FAMILIES.C is still "Christianity", and a control asserts the two really differ — an English-only projection fails that assertion. One assertion of mine failed on its own retraction first: it required the stale phrase to be ABSENT, but the corrected comment quotes it in order to record it. Requiring the absence of a phrase punishes documenting the error, so it now asserts the retraction is present instead. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| 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.