f7f4b8c1e8
The packet ships in 11 languages, every string translated. detectLocale() read ONLY document.documentElement.lang — and EVERY generated leaf page in this repo hardcodes lang="en" (measured: 20 of 20, later 34 of 34 after the tree grew). So on the built static tree — the jamstack case these bundles exist for — ten of the eleven translations could not be reached by any reader. Correct, complete, and invisible. Several ticks of translation work landed behind a door with no handle. ?lang= / ?locale= is now consulted FIRST, then the host page, then English. A query parameter is the smallest thing that makes them reachable: no per-language page, linkable and shareable, and the WordPress/Polylang path through <html lang> is untouched — a gate assertion keeps the leaf pages declaring a lang so that path cannot silently become the only way in. Both spellings are accepted because both are in use here (`lang` in profile configs, `locale` in the i18n layer) and guessing wrong is a silent no-op. ⚠ AND MAKING ARABIC REACHABLE EXPOSED THE NEXT PROBLEM. Only ONE component reads RTL_LOCALES today, so selecting ar would have given Arabic TEXT inside a left-to-right layout everywhere else — readable glyphs in the wrong place, which reads as a styling quirk rather than a bug. createAppI18n now reflects an RTL locale onto document.dir. It only ever SETS it, never clears it: a host page that already declares dir owns that decision, and stomping it to "ltr" for an English map embedded in an Arabic page would break the page around us. Verified: ?lang=ar sets dir=rtl in a real browser; ?lang=zz correctly falls through to English. detectLocale is exercised against its SHIPPED source across 7 cases including pt-BR -> pt. ★ One thing this tick taught me the hard way: rebuilding a bundle WITHOUT regenerating the tree leaves the leaf page carrying the OLD SRI hash, so the browser refuses the script and NOTHING MOUNTS — silently. I spent three probes reading an empty page before checking the integrity attribute. |
||
|---|---|---|
| .. | ||
| 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.