History

doxa-maps-88655c70 57fecfd0da A gate that asks whether anything is there — and it caught a dead bundle Wrote this after shipping a page that returned 200 for every asset, reported zero console errors, and was completely dead: a throw during setup dies inside the custom-element boundary. Zero errors is not the same as working, so this does not trust their absence — it looks for PRESENCE, on all five leaves, in five steps that each name their own failure: the tag is defined, the host is in the document, a shadowRoot is attached, it has children, it renders text. Its first real run went red on all five, and it was right. Every gospel leaf was dead with "Identifier 'Ge' has already been declared" — while the SRI hash still matched and every request still returned 200. My own doing: four profiles imported en/gospel.json directly for an English fallback, and library/i18n already pulls that exact file in through an eager glob, so the IIFE carried two instances of one module. The fix is one module: library/i18n now exports EN_MESSAGES and the profiles read it from there. The duplicate is gone. Measured after: all five leaves mount with 3,228 to 233,307 characters of rendered text, verify-gospel-map passes with 2,107 pins and the gap cutting to 370, and --poison confirms the check goes red on a page with no element at all. The lesson is the gate's whole reason to exist. I had rich assertions about pin counts and filters and none of them ran on data-tables, charts or the list, so a bundle-level failure could take out every leaf while the one gate I did run was pointed elsewhere. Cheap and universal beats rich and narrow for THIS question.		2026-09-25 09:52:25 +00:00
..
locales	The last English in the shared header, panel and facet rail — and a 24px touch target	2026-09-25 09:15:30 +00:00
index.js	A gate that asks whether anything is there — and it caught a dead bundle	2026-09-25 09:52:25 +00:00
README.md	consolidate docs into documentation/ and deployment shells into deployment/	2026-09-21 23:23:23 +00:00

README.md

library/i18n/ — the map's translations

One of the three customization seams (colors/, api/, i18n/). This one owns every user-facing string. Translations are one folder per locale, one JSON file per area, inlined at build time into a Vue I18n instance (one per <doxa-map>, so embeds don't bleed state).

  i18n/
  ┌───────────────────────────────┐
  │ index.js   ← engine, don't edit │
  │ locales/                        │
  │   en/  buttons.json legend.json …│  ← en is the source of truth + fallback
  │   es/ ar/ zh/ …  (same keys)     │  ← 11 shipped locales, drop in your own
  └───────────────────────────────┘
     filename → namespace:  buttons.json → $t('buttons.prayForThem')

11 shipped locales; ar renders right-to-left (RTL_LOCALES).
Add a language by copying locales/en/ to locales/<code>/ — never by editing index.js (except adding the code to SUPPORTED_LOCALES).
Missing keys fall back to English silently.

Adding or overriding a locale? The full contract (locale matrix, checklist, integration) is in ../../documentation/architecture/i18n.md.