09d03c60d2
The prayer API localises its labels from its own lang parameter, so the region and country NAMES follow whatever languageCode resolves to. That computed read props and profile-config only — never the URL. So a DIRECT LINK, which is the URL a person actually sends someone, went through detectLocale() for the chrome and then asked the API in English: Arabic headings around English region names. MEASURED, and only visible because the two channels were compared rather than each checked alone: region-dashboards rendered 597 Arabic chrome characters through profile-config against 309 through ?lang=ar, and regions-mfe 2709 against 748. The host-locale gate passes both, because it asks host >= ref/2 and cannot see an asymmetry in that direction. Diffing the two renders element by element named the whole gap exactly: the seven region labels in the chooser legend (.rd-regionkey__label) and the seven row links in the table (.rd-row-link). The reader is EXTRACTED, not copied. library/i18n/index.js already parsed ?lang= / ?locale= inside detectLocale; it is now exported as localeFromUrl() and used in both places, so the data call and the chrome can never disagree about what the URL asked for. Re-implementing those two lines in the plugin would have been a second copy of one fact, which is how the asset-path bug and the PosterWall fallback table both went wrong. After: ?lang=ar renders 30 Arabic elements against profile-config's 30 on region-dashboards, and 42 against 42 on regions-mfe — 0 strings left English on the shared-link path. All 23 bundles rebuilt because the library file reaches them; composite freshness PASS, check:sri PASS. |
||
|---|---|---|
| .. | ||
| 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.