bc4d1f54bd
Two defects, both invisible to an English diff because both sides were English. 1. THE LIST LEAF NEVER GOT THE ?lang= FIX. I repaired languageCode in region-dashboards.vue and stopped; regions-list.vue has the same computed and the same comment block describing the same defect, and it still read only props and profile-config. So a shared /regions-list/?lang=ar link rendered "المناطق" as its heading and then listed all 41 countries as "Angola", "Benin", "Cameroon". 2. OUR ARABIC WAS NOT THEIRS. Ten strings used vocabulary doxa.life does not use: "مجموعة بشرية" where they say "مجموعة شعبية" for a people group, "مُخْدُومَة" where they vowelise it "مَخْدُومَة", and for unengaged an invented "غير مبشرة" / "الهدف هو القضاء على…" where they simply say "غير مَخْدُومَة". Each replacement is a string read off their live /ar/ pages in this session, with our placeholders re-inserted where their rendered page carried the values — copied, not translated, which is what the brief asks for and what I can defend. MEASURED, by the census in Arabic: 190 unaccounted additions and 8 omissions before, 9 and 8 after the leaf fix, 0 and 0 after the vocabulary. The English census reported a perfect clone throughout, which is exactly why the locale dimension was worth running. The sanctioned list now resolves through our own catalogue, so a permission granted in English is the same permission in Arabic: "عرض ملصقات الدولة" is recognised as the Driver's country-poster toggle instead of being reported as an invention. Hardcoding its Arabic would only have moved the problem to zh. Also repaired every probe URL for the dx-maps rename — 180 paths across 153 files were still pointing at /doxa-maps/, which now 404s, so the whole measurement apparatus was aimed at a tree that no longer exists. Replaced only the slash-delimited segment, leaving doxa-maps-spa and the repo URL untouched, and proved the repair by re-running the English census to its known-good baseline before trusting anything else. Built ONLY regions-dashboard (rule 5: studio owns the full build). This touches library/i18n/locales/ar/regions.json, so other bundles need a consumer rebuild — messaging studio with the sha. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| 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.