The ⓘ is now the column's top control, and its one-time pointer runs sideways from it across the
map's top band. On a phone that band is these maps' legend (title and fold button), and MapToolbar's
phone rule put the column at top:72px inside it, so the pointer lay over the legend's title and
buttons. Below 700px the column now starts 8px under the FOLDED legend's measured bottom, whatever its
height in each language. It is measured only while folded and before the toolbar exists, so opening
the legend never moves the controls. Desktop is unchanged.
Rebuilds cities-internet and gospel-resources, with their pages and the two manifests.
Their control column renders only once the map exists, after the data, which can take tens of
seconds on a slow phone. At mount each map now tells the gallery's MapInfo that a control is on its
way (Prayer Progress's announcement), so MapInfo waits for the map instead of flashing its floating
ⓘ first. A failure or an unmount before the map exists withdraws the promise, so the floating ⓘ
shows at once. Gospel's single-card page builds no map and promises nothing.
Rebuilds cities-internet and gospel-resources, with their pages and the two manifests.
The ⓘ becomes the first round control in each map's own column (MapInfoButton, as Prayer Progress
has it), and each tab's gallery row says trigger: 'control', so there is exactly one ⓘ: the control.
MapInfo keeps its fail-open, so a page where the control never arrives still gets the floating one.
Rebuilds cities-internet, gospel-resources and doxa-maps-spa, with their pages and the two manifests.
The desktop card was placed with right:14px while the legend sits at the inline start. In a
right-to-left page the legend mirrors to the right and the card stayed there, so opening any
people group or country covered the legend at every desktop width. The card now sits at the
inline end, as Cities' copy of the same rule already did. English is unchanged.
Rebuilds gospel-resources only, with its five pages and the two manifests.
resources-map.meta.json carried NO stage, so the manifest defaulted it to
experimental — while doxa-maps-spa, the gallery that becomes Deep Research,
mounts it: doxa-maps-spa.meta.json composes "gospel-resources/resources-map"
and TAB_DEFS names it as the Gospel Resources tab. The record disagreed with
what ships, and the record was the part that was wrong.
WHAT THIS CHANGES: the manifest stage, and nothing a reader sees. Verified —
the diff moves one "experimental" to one "production" and ZERO sha384 hashes.
No bundle is rebuilt and no byte of any map changes.
The stricter production gates now apply to this profile and it passes them:
gates:pre 103 PASS / 0 FAIL / 1 NOT MEASURED of 104. That is the part worth
having, because marking something production is only honest if it then has to
meet the production bar.
NOT a decision about which profile the Deep Research page SHOULD show.
gospel-dashboard is the production composite and remains the better end state;
it is not switched to today because its .gd-map is sized 80svh — a viewport
unit inside a pane that is not the viewport — which against rega's measured
panes gives the map 91% of the pane at 1440x900 and 95% at 390x844, and
because it has never been shot inside the gallery. That fix is written and
held local for after the deadline.
Resolving package.json conflicts by unioning unique lines is right for a file
that holds one entry per line. Applied to ordinary source it duplicates
declarations, because both sides of a hunk keep their copy and nothing
de-duplicates across the join.
Eleven plugin entry points ended with the same import twice, and the poster
renderer with two identical `const sheet`. Each is a SyntaxError: every one of
those bundles would have failed to build, and the poster export would not run.
Found by parse-checking every changed .js against the merge base, not by the
gates -- gates:pre passed 101 of 102 with all twelve files broken, because its
parse gates do not cover plugin entry points.
One measurement trap worth recording. `node --check` on a .js file parses it as
CommonJS, so a bare `import` is a syntax error and ALL 28 entry points appear
broken, on development too. That reading says the tree is on fire and is simply
wrong. Copying each file to a .mjs and checking that parses it as a module,
which separates the eleven that are genuinely broken here from the rest that
are fine.
Same defect as cities-internet's list and table: no :host rule at all, so the
element falls back to display:inline with no height while .gt is
position:absolute;inset:0 — which then resolves against whatever the partner
page has positioned.
TWO MOUNTS, ONE RULE, and they do not collide:
- STANDALONE (data-tables.meta.json) this is its own custom element, so :host
applies and .gt is finally contained.
- COMPOSED, gospel-dashboard renders <DataTables/> as an inline Vue component
with no shadow host of its own, so :host matches nothing there. Its
'.gd-tables .gt{position:static;…}' override (gospel-dashboard.vue:81) keeps
working, which is what lets the stacked section take its natural height and the
page scroll. That override records a MEASURED failure — docScrollHeight 900
against clientHeight 900, a wheel gesture moving 0px — and must not return.
min-height, not height alone: with no height, .gt's inset:0 would give the table
0px in an auto-height box, so it would stop escaping by becoming invisible. A
floor gives an auto host something to grow from; a definite-height slot still
decides through height:100%.
NOT the ProfileLoader 100dvh floor (ProfileLoader.vue:410), which is the separate
upstream cause of the connectivity-map overflow and is studio's card. .gt is not
that wrapper, so this fix stands on its own.
(cherry picked from commit 10f2a5c13f8d08c0086ada8eafa4ad819863bd0a)
formatList (R29) replaces join(', ') at the two sites that a reader sees. The
separator was never a missing key — no key can fix punctuation between
interpolated values — which is why both survived every i18n gate.
connectivity-map.vue:365, CONJUNCTION. The Indian states with no boundary are
ALL missing one. The names land inside a translated sentence at :595, and the ar
message reads "لا توجد بعد حدود ولاية لـ {names}: …", so English commas were
being printed inside Arabic prose.
GiCombos.vue:49, DISJUNCTION, decided from the matcher and not from what reads
better: useSelectionBus.js:299 tests cur.includes(value) and toggleFilterValue
adds to the list, so two values on one facet WIDEN the result set. "Africa and
Asia" would state the opposite of what the filter does. This changes the English
too — "Africa, Asia" becomes "Africa or Asia" — which is a gain, because a comma
silently reads as ALL.
Measured, the same three names and two facet values through each type:
en "Ladakh, Puducherry, and Chandigarh" "Africa or Asia"
ar "Ladakh وPuducherry وChandigarh" "Africa أو Asia"
zh "Ladakh、Puducherry和Chandigarh" "Africa或Asia"
was "Ladakh, Puducherry, Chandigarh" "Africa, Asia"
ar joins with و and no comma at all; zh uses 、. Neither is reachable by keying.
Not converted, and deliberately: useBoard.js:126 is a console.warn for
developers, and rudder-voice.vue:971 is in a component with zero i18n imports and
no catalogue area — English by construction, so it converts with the rest of
Rudder if Rudder is ever localized.
Source only. The rebuilds are regenerated after this rebases onto landed R29.
The chips a reader sees on a group's sheet — "Scripture,", "Bible video",
"Training", "Gospel presentation" — were plain template text. All four already
had keys with real ar and zh translations, so this routes them through
gospel.res.* and adds nothing: scripture, bibleVideo, training,
gospelPresentation.
WHAT IS DELIBERATELY LEFT ALONE, because it is not a label:
- g.audio.m keeps its raw value and its 'audio' default. That is the table's own
media descriptor, data rather than UI text.
- gospel-resource-rows.js is already correct. add(title, type, …) translates
title through tx() and keeps type as the category identifier the rows are
grouped by; the gate flags those type strings, but translating them would
break the grouping — the same value/label trap as the region headings.
- d.s.replace('Open Bible Stories', 'Bible Stories') at :2754 rewrites a DATA
value, not a label.
- data-tables.vue:122 already carries labelKey; its `en:` is the fallback beside
it, by design.
- The caveat prose (Driver row 80) and the title= tooltips (row 120) are
untouched and stay that way until those rows are answered.
check:hardcoded-english on gospel-resources: 91 -> 87, which is these four.
The gate matched "Driver" only, so "THE DRIVER'S ASK" and "HELD FOR THE DRIVER"
passed unseen — and so did my own verification, which used the same
case-sensitive pattern and reported zero. I checked the thing the gate checked
rather than the thing that mattered.
Seven lines across six files: five banner headings, one quoted requirement, and
the row-130 marker. Same rule as the first sweep — keep the reason, drop the
speaker — with the verbatim quote in build-doxa-gospel-access.mjs restated as
the question the map answers, since its content is the requirement and its
framing was attribution.
Comment-only: 0 non-comment lines changed, tree regenerates identically.
Case-insensitive grep across all three plugins now returns nothing.
gospel-resource-rows.js builds each resource row's display text, and its
fallbacks were English literals: a record with no name of its own showed
"Scripture in this language", "Audio Scripture", "Listen in a browser" to an
Arabic or Chinese reader — precisely the rows whose source data was least
complete. check:hardcoded-english does not read .js files, which is why the
bundle's sweep never saw them.
Thirteen keys in eleven locales, and the translator is PASSED IN rather than
imported: the module is a pure function with no component context, and it stays
optional, so a caller without one degrades to the English written at the call
site instead of throwing.
Three publisher names stay verbatim — JESUS Film, Scripture Earth, Zume — but
where a name sits inside an ordinary phrase the phrase is keyed and the name is
INTERPOLATED, so "Zume discipleship training" translates around a brand a
translator never retypes. SE_KIND's values are displayed and take keys; its keys
are the upstream feed's codes and must not be touched.
Verified by running the module both ways: without a translator every row reads as
it does today; with an Arabic one the labels and scopes are Arabic while
"Scripture Earth" and "Zume" are unchanged.
ROUTED TO STUDIO, not self-landed: the eleven locale files make this a library
change. The route test says 11, and the last time I judged a landing by which
plugin the work was for rather than which directories it touched, the scan ran
against most of the fleet and timed out twice.
The 36 baselined references in gospel-internet (23), gospel-resources (9) and
cities-internet (4) each wrapped a real engineering reason around an attribution.
The reason is what a reader needs; the speaker is process vocabulary that does not
belong in shipped text.
Every one is rewritten in place, keeping the measurement and the date where they
were there: "NUMERALS ARE HELD fleet-wide (2026-09-26)", "(2026-09-27: one more
level of zoom-out was needed)", "Reported from use: it overlapped the bottom of
the page". Where a quote carried the requirement, the requirement is now stated
directly rather than quoted.
Comment-only: 36 insertions against 36 deletions, one line for one line, and no
built text changes. Route test passes — 0 files under library/ or internal/, so
this self-lands rather than going through studio.
Two things I nearly shipped by accident, both caught before committing:
`git add -A` swept in a 1,961-line vite.config timestamp artefact from my own
build, and editing the JSON meta through a parser reformatted "composes" from one
line to three. The artefact is deleted and the JSON is edited as a string, so the
diff is only what I meant to change.
Found while classifying the remainder rather than by the gate pointing at them:
the search box's aria-label was hardcoded English — screen-reader text, the same
class as the resize-handle bug that check:i18n-keys-exist documents — along with
the legend's open/close label, the three gap-chart titles, "unnamed language",
the unchecked-link notice, and "no code", which appears at six call sites and is
now one key.
Nine keys, sixteen call sites. 102 -> 88.
These were hiding inside the 102 I had described as mostly-deliberate. The
classification was worth doing for its own sake: four of the five classes really
are deliberate, but the fifth had real defects in it, and I would not have found
them by reading the count.
Five more keys: the table's loading line, the language sheet's population and
countries line, and the two bold lead-ins that introduce the caveat prose in
resources-list. The caveat prose itself stays inside its dir="ltr" island, which
the gate already marks deliberate — only the heading that introduces it is
language.
Not touched, and not oversights: "· GRN", "· Zume" and "· Door43" are a separator
plus a publisher's name, on lines whose translatable half is ALREADY keyed. A
brand name after a middot is not a sentence.
106 -> 102.
"Showing {shown} of {total}." appears twice, for the with-resources and
without-resources lists, and is ONE key used twice. The population suffix and the
related-language line join it; "way in:" reuses the key the gap list already has
rather than authoring a second one for the same words.
Three new keys, five call sites.
Four fragments around three counts, two bold words and a bdi island — "people
groups are", "people,", "an estimated", "deaths per day." — become one message
with named slots, the same shape as the charts hero.
Verified through a real createI18n: en renders as today, ar carries the clause
order Arabic needs, zh reorders too. The counts and the quoted phrase go in as
values, so the bold and the dir="ltr" survive without a translator reproducing
markup.
115 -> 111.
Twelve more keys across resources-map: the two resource chips ("Scripture,
{medium} · {source}" and "Bible video · {source}", where the type word is
language and the source is data), the sheet headings that carry a count, the
country line, the pray count, and the loading notice.
The separators stay out of the catalogue. A "·" between a type and a source is
structure, not prose, and a translator asked to reproduce it would eventually get
it wrong in a language that does not use it — so the punctuation lives in the
message and only the words vary.
124 -> 115 findings. The ratio is back to roughly one finding per key now the
duplicated spans are gone, which is what I said would happen once the one-off
sentences began.
resources-map's gap list read as fragments around its values: "{count} people ·
{iso3}", "way in: {via}", "has {what} — no text found", and a "Showing only …"
whose bold phrase came from a four-branch conditional. Each was a sentence broken
around the data it carries, which is the shape that cannot be reordered.
Nine keys, and one of them does three jobs: the population line appears three
times in near-identical sibling spans, so it is ONE key used three times rather
than three keys — the duplication was in the template, not in the language.
The four filter descriptions are their own keys and slot into the sentence, so a
translator can move "Showing only" around the phrase rather than being handed two
halves to join in English order.
144 -> 124 findings for eleven keys. The ratio is better than the proving case
because the duplicates collapsed; it will worsen again on the one-off sentences.
charts.vue's hero read as six fragments concatenated around three counts and a
bdi island: "of", "languages have", "— the languages of", "people." Arabic does
not put those clauses in that order, so translating the fragments would have
given Arabic words in English order — grammatically broken, and worse than
leaving it English, because it looks translated and nobody re-checks it.
Now one message with named placeholders through useSentence. The counts and the
quoted phrase go in as VALUES, so the bold and the dir="ltr" survive without a
translator ever reproducing markup, and keep() hands the placeholders back to t()
intact — without it the lookup blanks them and the sentence renders with no
values at all.
Proven through a real createI18n rather than in isolation, which is the lesson
from the keep() trap: en renders as it does today, and ar and ru both LEAD with
the object and put the counts after — the reordering that fragment-by-fragment
translation cannot express. zh reorders too.
The gate moves 144 -> 142 for this one sentence. That is the honest number: six
fragments collapse into one key, but the gate counts findings, not fragments, so
the count falls more slowly than the work proceeds. ~26 fragments remain.
Four rules in the resources list and tables are physical where the thing they
position follows READING ORDER, so they do not mirror under dir="rtl":
- .r-code sat at margin-left of the language name, landing before the name in Arabic
- .res a + a used margin-left for the gap that exists so "Holy Bible" and
"JESUS Film" do not read as one string; mirrored, the gap moves outside the
pair and the two links run together again
- .r-pop aligned right, which is the START of an Arabic row, not the end
- .gt-filter's accent bar marked the left edge rather than the leading edge
Now inline properties. The three border-left-color rules in resources-map.vue
are deliberately untouched: each sits on an element carrying dir="ltr", so its
edge is physical in every locale by design.
Twelve globals were set across three plugins and none was ever deleted. Each
pins whatever it closes over — a map instance pins its canvas, its sources and
through them the whole app — so every mount left another copy behind, measured
elsewhere at roughly 10 MB each.
Released as a set rather than one at a time. A block that sets several globals
and clears the obvious one leaks the rest silently, and the obvious one is
whichever the author happened to remember.
Identity-checked, which is why the value is recorded as it is set rather than
cleared by name. Two instances can share a page, and clearing by name alone
would let the second unmount delete the first's live hooks — trading a leak for
a harder bug in which a live map loses its test surface at a distance.
A first attempt compared against a name that did not exist. Inside the try/catch
that guards these, the ReferenceError was swallowed and every delete silently did
nothing — a leak fix that looks exactly like a leak fix and leaks. The guard that
makes the assignment safe is the same guard that hides its failure, which is the
argument for recording what was set rather than inferring it at teardown.
Two things the Driver found, both about a control being in the reader's way
rather than about it not working.
The collapse caret was absolutely positioned over the panel's top-right, and the
title was hidden when collapsed — so collapsing left a lone glyph floating on the
map with nothing to say what it would reopen. It now sits inline in a header row
beside the title, which is where the shared legend puts its own: a flex item with
no positioning at all. The header stays visible when collapsed, so the control
always carries its label.
Side by side there is room for the target and its decoder. Stacked on a narrow
pane there is not: the decoder is a tall card that pushes the chart off the
screen, so a reader who asked to see the target got a glossary. Below the
breakpoint the legend now starts closed behind a named toggle. It is not hidden —
the control says what it opens, and opening is one tap.
The toggle reuses keys that already exist in every locale rather than adding a
word of its own. A new string would have meant eleven catalogue entries owned by
another tab and landing in another batch: a cross-owner dependency bought for one
label, when the fleet already had the sentence.
Mobile has had a fold control since the narrow layout existed; desktop had none,
so a reader who wanted to see the map underneath had no way to move the legend
off it. The state was already there — every section read "not narrow OR open", so
on desktop the OR was always satisfied and the flag governed nothing. Now the
flag alone decides at both widths.
The control is deliberately not a new one. Same 22x20 caret, same rotation, same
aria contract as the shared SemanticTreeLegend's collapse button, which the
mobile legend also copies. Matching it costs nothing and means a reader who has
met one of these legends has met this one.
Collapsed, the panel shrinks to the caret. Hiding the contents alone would have
left a 380px box of empty background over the map: the reader presses collapse
and gets a blank panel instead of their map, which is worse than having no
control at all.
The choice is remembered for the session, so it survives working with the map but
not a fresh visit, and a remembered choice beats the width default — otherwise
dragging a window across the breakpoint would silently reopen a legend that had
been deliberately closed, undoing a decision rather than responding to one.
Storage access is wrapped: a sandboxed embed throws on it, and a legend that
cannot remember is much better than a map that will not load.
My scripted migration inserted the import behind a guard that silently did not fire:
`if 'defineMapElement' not in s.split('function')[0]` became false as soon as the
inserted CALL appeared before the first `function` keyword — so the files that most
needed the import were exactly the ones that did not get it. 11 of 16.
Every one of those elements would have thrown "defineMapElement is not defined" on
load. A bundler does not error on a free identifier; only loading does. studio caught it
in L64 via landing-preconditions, which imports each profile, and fixed it there
(37f75601) plus added an arm to check:element-bootstrap.
This repairs the same 11 on this branch so it is not a landmine if it lands after L64,
and it is byte-equivalent to studio's fix in effect. Verified by PARSING each entry and
resolving the identifier against its import bindings — 16 of 16 bound — rather than by
re-running the kind of regex that wrote the bug.
The element-bootstrap migration called defineMapElement in eleven entry files that never
imported it. A build does not fail on an unbound name; the element does, the moment it loads,
with 'defineMapElement is not defined'. The landing precondition caught it by importing each
profile. check:element-bootstrap now fails when an entry calls the helper without importing it.
Goal (c), and it turned into a goal (d) fix. Every profile element is
defineCustomElement(ProfileLoader, { configureApp }), and the configureApp has four
steps. The fourth, app.provide('appI18n', i18n), is the one that gets dropped.
ProfileLoader injects that instance (ProfileLoader.vue:176) to drive its locale from
profile-config. Without the provide the watcher holds null and the drive NEVER RUNS --
while setRuntimeLocale() on the next line still fires, so tStatic strings DO follow the
host. The element renders a convincing MIXTURE of the reader's language and English, and
nothing throws, because the t() shim falls back to its key. It reads as "a few strings
not translated yet".
SHIPPING THAT TODAY: country-posters, key-cities, gospel-resources, cities-internet and
my-upg-100-list. regions-plugin censused all 19 entry files independently and found the
same five and no sixth. The measurement is regions-dashboard's, from when they hit it:
a Spanish catalogue present, es set, and every t() string still English.
All sixteen entries now call library/elements/defineMapElement.js, so the five are fixed
by construction rather than by five separate edits. Behaviour is otherwise identical --
same options, same element names, same per-plugin extras. wall-of-people-groups needed
the helper to hand its pinia back, because it takes a store off its own instance and a
helper that hid pinia would have given it a second one: two stores and a silent state
split.
★ AND THE CENSUS THAT RECOMMENDED THIS SAW FOUR OF SIXTEEN. My detector hashed function
BODIES; eleven sites are not `function buildXElement()` at all, they are
`const El = defineCustomElement(...)`. I wrote "every number here is a lower bound" in
the census as a caveat and it was the headline within the hour -- a 4x undercount of the
item it recommended. So this gate greps for the SHAPE, not for a known list: a check
written around the four that matched would have passed the twelve that did not.
check-element-bootstrap has two arms. No entry may build a profile element by hand, and
the helper itself must provide appI18n -- PLANTED as a negative case, so the regression
cannot return by editing library instead of a plugin. It also fails if it finds fewer
than ten entries, because a detection that stops matching reports the same green as a
tree with no problems.
THE PLANT CAUGHT TWO BUGS IN THIS GATE BEFORE IT CAUGHT ANYTHING ELSE. The predicate
matched the helper's DOCSTRING, so it would have passed a helper that only mentions the
provide in prose -- comments are stripped now, because a check that reads comments is
reading the author's intentions rather than the program. And the plant itself used /m
instead of /gm, so it deleted the documentation and left the code, then reported that it
could not detect an absence that was not there.
Goal (c), and it turned into a goal (d) fix. Every profile element is
defineCustomElement(ProfileLoader, { configureApp }), and the configureApp has four
steps. The fourth, app.provide('appI18n', i18n), is the one that gets dropped.
ProfileLoader injects that instance (ProfileLoader.vue:176) to drive its locale from
profile-config. Without the provide the watcher holds null and the drive NEVER RUNS --
while setRuntimeLocale() on the next line still fires, so tStatic strings DO follow the
host. The element renders a convincing MIXTURE of the reader's language and English, and
nothing throws, because the t() shim falls back to its key. It reads as "a few strings
not translated yet".
SHIPPING THAT TODAY: country-posters, key-cities, gospel-resources, cities-internet and
my-upg-100-list. regions-plugin censused all 19 entry files independently and found the
same five and no sixth. The measurement is regions-dashboard's, from when they hit it:
a Spanish catalogue present, es set, and every t() string still English.
All sixteen entries now call library/elements/defineMapElement.js, so the five are fixed
by construction rather than by five separate edits. Behaviour is otherwise identical --
same options, same element names, same per-plugin extras. wall-of-people-groups needed
the helper to hand its pinia back, because it takes a store off its own instance and a
helper that hid pinia would have given it a second one: two stores and a silent state
split.
★ AND THE CENSUS THAT RECOMMENDED THIS SAW FOUR OF SIXTEEN. My detector hashed function
BODIES; eleven sites are not `function buildXElement()` at all, they are
`const El = defineCustomElement(...)`. I wrote "every number here is a lower bound" in
the census as a caveat and it was the headline within the hour -- a 4x undercount of the
item it recommended. So this gate greps for the SHAPE, not for a known list: a check
written around the four that matched would have passed the twelve that did not.
check-element-bootstrap has two arms. No entry may build a profile element by hand, and
the helper itself must provide appI18n -- PLANTED as a negative case, so the regression
cannot return by editing library instead of a plugin. It also fails if it finds fewer
than ten entries, because a detection that stops matching reports the same green as a
tree with no problems.
THE PLANT CAUGHT TWO BUGS IN THIS GATE BEFORE IT CAUGHT ANYTHING ELSE. The predicate
matched the helper's DOCSTRING, so it would have passed a helper that only mentions the
provide in prose -- comments are stripped now, because a check that reads comments is
reading the author's intentions rather than the program. And the plant itself used /m
instead of /gm, so it deleted the documentation and left the code, then reported that it
could not detect an absence that was not there.
L56 published the catalogue keys these three sites were waiting for, so the template now asks for
them instead of carrying the English:
the gap list's "related:" label -> gospel.gapList.relatedLabel
the legend's "Show all N" clear button -> gospel.filter.showAll, with the count as a placeholder
the detail panel's "Nothing in X itself" -> gospel.related.nothingInItself
Each was chosen because the swap costs no markup: the <em> and <b> wrap the whole phrase, so they
stay outside the call and the emphasis survives. The sites where a <b> sits INSIDE the sentence --
"Showing only <b>…</b>." above all -- are deliberately not in this commit, because the key is one
whole sentence and using it would silently drop the emphasis that distinguishes the filter's value
from its label. That needs a markup-preserving form, not a quiet visual regression on a production
map.
Measured, not assumed: hardcoded-english for this plugin 147 -> 144, and every one of the 72 keys
the leaf now references resolves in the catalogue. That last check caught a mistake in this very
change -- a fallback I wrote as t('gospel.state.thisVariety'), which does not exist and would have
rendered the key name to a reader. It is back to its literal until a key exists for it.
i18n parity and never-translated both pass; gospel's own render gate passes in ar, zh, ru and hi.
Rebuilt this bundle only, then fix:sri; check:sri is green at 64 leaves.
Regions: the country and region counts under the dashboard title were English
template literals; they are now label keys ('Countries: %count%') in all eleven
locales, which also sidesteps plural forms.
Gospel: the Zume chip joined 'in' + a language name, which reads backwards in
Hindi; it is now one phrase key with a {language} placeholder.
UPG-100: the Batch Select button title comes from legend.title.batchSelect.
Eight CSS declarations in the production profile still named a physical side, so in Arabic they
pinned translated text to the left: the legend key's wrapped label, the search-match rows, the
people-group buttons in the gap list and in the detail panel, the error line, two chip margins,
and the row-count badge beside each table tab. Every one of them now uses the logical property —
text-align:start, margin-inline-start — which is identical to today in every left-to-right locale
and correct in the two right-to-left ones.
Found by auditing the production profile's localization rather than by a rendering failure, which
is how this kind of defect stays in: the Arabic page looks translated, because it is, and only the
alignment quietly disagrees with it.
Nothing in the English-prose islands changed. Those carry dir="ltr" on purpose — the caveats stay
English by the standing ruling, and the isolation is what keeps them from disturbing the Arabic
text around them.
Rebuilt gospel-resources only, then fix:sri; check:sri passes at 64/64 leaves.
charts, data-tables and resources-list had no <profile>.meta.json at all, so the manifest carried
no label for them and the Studio rail humanized the folder name: "Charts", "Data Tables",
"Resources List". Those say what the file is called, not what the page answers.
Each now has a meta with a label and its stage:
charts Gospel Resources -- where the gap is, by language
data-tables Gospel Resources -- every resource and every gap, in tables
resources-list Gospel Resources -- what each people group has
All three declare "stage": "experimental" EXPLICITLY, which is what they already were. A meta-less
profile and a meta without a stage key both default to experimental in profile-meta.mjs, so the
value would otherwise rest on that default -- and these three sit in a bundle whose stage reads
production through gospel-dashboard, so a later change to the default would silently promote them.
Measured after the change: the three stay experimental, gospel-dashboard stays production, and
bundleStage still returns production.
Type is deliberately not declared. generate-tree resolves the composition tier from meta.json
`type`, not from whether the file exists, so omitting it leaves all three inferred `single`
exactly as before. Nothing in the manifest moves except the three labels and three stage values
that already held.
check:public-hygiene is the white-label gate for the giveaway, and translator-org-links.json
shipped an internal role noun: the held-Bible-Society reason read "...is the Driver's ruling, not
this script's". A recipient reading our data files should not meet our process vocabulary. It now
reads "a product ruling", which keeps the meaning exactly — the point was always that this build
will not decide a doctrine question on its own.
Fixed in the script that writes the table, not the artifact, or the next build would put it back;
the same phrase in that file's header comment went too, rather than waiting to be flagged
separately now studio has closed the comment half of this class.
Regenerated by re-running the verifier: 16 of 16 organisations answered again, so the table is
current rather than hand-edited. My published tables now carry no internal vocabulary — checked
with word boundaries across all of them, which is also how I learned the six "rega" hits reported
in my sweep were the word "aggregates".
tOr() rendered English while a key was in flight. All eleven keys it guarded are on main, so it
is gone and every call site reads the catalogue: nParts, engineMissing, sheet.loading,
guide.wayInAll/wayInSome/wayInWhat, legend.hnrTip, guide.howNumbersMade, guide.isSignLanguage,
sheet.linkCopied, sheet.share.
I compared each default against the catalogue before deleting it, rather than assuming they
matched — deleting a fallback silently changes what a reader sees. Ten were identical. The
eleventh was not: gospel.sheet.share held my "Share this card" against the catalogue's "Share".
The catalogue wins, because it is translated in eleven locales where my phrase was not and a
button inside a card need not restate its container, so THE SHARE BUTTON NOW READS "Share" —
a visible change, deliberate, and the shorter label suits the 390px screen where those tap
targets were just fixed.
The four parameterised calls needed doing by hand: my regex for tOr(key, english, params)
stopped at the first ")" inside fmt(...), so it silently converted seven of eleven and left
four. Counted the remainder instead of trusting the count it printed.
gates:pre 11/11, ENGLISH-LEAKS PASS, and the built bundle no longer contains the inline English.
rega: the Scripture scope stayed English under ar, because gospel.res.newTestament and
gospel.res.fullBible exist in NO locale — while gospel.charts.newTestament and
gospel.charts.fullBible have existed, translated, in all eleven all along. Every locale was
falling back to my English defaults, and even en read my lowercase "full Bible" against the
catalogue's "Full Bible".
I asked studio for three new keys without checking whether the words were already owned. Two of
them were. The chip now reads the existing pair — verified in the built bundle: the Arabic
"العهد الجديد" and "الكتاب المقدس كاملاً" are both in it — and only the part count still needs a
key of its own, gospel.res.nParts with {n}, which I have narrowed studio's request to.
Two keys for one word is exactly the drift I have spent this flight fixing in other people's
code. The namespace reads oddly for a map chip, and that is the smaller problem.
dx-shepherd caught what I had just shipped: "full Bible", "New Testament" and "N parts" were
being generated in the BUILDER, so English was baked into data that no locale can translate and
no catalogue owns. The same mistake I have been fixing in other people's surfaces all day, made
one commit earlier by me.
The builder now ships FCBH's part count and nothing else — 27 on 400 codes, 66 on 41, another
count on 82, none on 367 — and the leaf names it through tOr(), so it localises the moment
studio adds three keys: gospel.res.newTestament, gospel.res.fullBible and gospel.res.nParts
with {n}. English inline until then, as always.
A count that is neither 27 nor 66 is still reported as itself and never rounded up to a
Testament, and no count still names only the source.
The Scripture chip named its source ("Faith Comes By Hearing") and stopped there, for 887
codes. FCBH publishes its own verse scope in the same record — au.vsc, "N parts, FIRST to
LAST" — and 567 of those 766 carry one: 400 New Testaments, 41 full Bibles, the rest partial.
A catalyst standing with a group needs to know whether that link is a whole Bible or two
books, and the data said so all along.
The chip now reads "Scripture · checked (New Testament — Faith Comes By Hearing)". 27 and 66
are named as Testament and Bible; anything else reports the part count FCBH claims and is never
rounded up. 367 sx codes still carry no scope — Scripture Earth's 104 and Door43's 17 publish
none in this record, and 47 FCBH rows omit it — and those say only the source, which is the
honest thing to say when the scope is unknown.
Found because go-int asked whether the FCBH text is a New Testament. It is a fair question to
ask of a map that had the answer in a field it never rendered. Their tree now reads the same
field and their green count went 128 to 195 across the roster.
Still FCBH's claim, cited, not counted book by book here — the same standard as the rest of
this corpus, and it is on the chip rather than buried in a builder.
1 THE CHIPS SAID "unchecked" ON VERIFIED LINKS. Card mode never fetches the verification table,
so every chip understated the evidence behind it — caught on central-sama, whose Scripture and
film are both verified. Each shard now carries the states for its OWN urls, keyed by url exactly
as linkVerify is, so vchip() and vtitle() work unchanged. Shards grew 8.0 KB to 14.0 KB mean,
29 KB worst; against 6,051 KB for the map that is a price worth paying for not lying about
evidence.
2 MY GATE'S FALSE NEGATIVE, which cost rega a round: it asserted
text.includes(slug.split('-')[0]) — "abai" against a rendered "Abai Sungai". A slug fragment is
not a name. It compares the roster's name, case-folded, anywhere in the card.
3 THE EMPTY GREY BAND. The sheet is a bottom panel capped at 62% of the map; in card mode there
is no map under it, so a phone showed 285px of grey above it. Full height in card mode, and the
border radius goes with it.
4 THE CLOSE BUTTON with nothing behind it — hidden in card mode, both instances of it.
gates:pre 11/11, LINK-COVERAGE 12,292 unchanged, SFC-PARSE PASS. rega spot-checks after landing
per dx-shepherd; the render claim is still not mine to make.
Third report of a blank card, and the root cause was never a missing field — it was two code
paths producing "the same" object. build-field-cards.mjs copied groupAt()'s 39 fields by hand
and missed door43, which exists only in that normalizer, so the sheet's
`!selectedGroup.door43.length` threw on undefined. I fixed a value, then a timing, then would
have added door43 and waited for the fourth.
The shard now ships the RAW INPUTS the map itself holds — the pin row, the whole code record,
the country name and the two bridge records — and the leaf's groupFrom() normalizes both
paths. groupAt(i) is a three-line wrapper over it. A field added to the sheet reaches the card
with no second edit, and forgetting one is no longer possible. The code record is passed WHOLE
rather than picked over, because picking fields is exactly the mistake above. Shards got
smaller doing it: mean 8.0 KB against 9.1.
Two sheet-level sources the card fetches nothing for are seeded from the shard: the prayer page
(prayIndex) and the SUN block. Both matter most to this persona — a catalyst with a Deaf group,
or one handing someone a prayer page — and both were silently absent while the card "worked".
Verified statically, since I cannot render: every one of the 28 fields the sheet reads off
selectedGroup is produced by groupFrom, so the two paths cannot disagree about any of them.
rega has the render.
The sheet tested scripture_url alone, so for every code whose readable text is NOT at c.s it
rendered "Scripture · none found". 887 codes keep theirs elsewhere — on the Faith Comes By
Hearing record, on Scripture Earth, or in a Door43 translation — and 332 field cards carry
one. A catalyst reading that chip was told there is nothing to read while the link existed.
The chip now links `sx` and NAMES its source, because a reader deserves to know they are
being sent to an audio site to read: "Scripture · checked (Faith Comes By Hearing)". The
verification state and title come from the same record as any other link, so nothing here is
claimed that the link record does not already support. The card carries sx for the same
reason — the tier that promises Scripture and the panel that shows it must agree.
Two placement mistakes of mine, both caught by checking the DATA rather than the diff: the
first edit matched `credit: c.cr || null` in the bridge helper instead of the card object, and
a str.replace with no match is a silent no-op that reports success. The card had no sx and
said so when I looked for it, which is why the second attempt asserted its anchor.
go-int cross-checked 20 roster languages with "no New Testament found in the pools" against
open-data signals. Thirteen of the twenty had readable text all along — on a record the tier
could not see — and chasing that found one rule written four times and wrong in two of them.
THE BUG. tierOfCode tested `!!c.s`, one field, while this build's own hasReadableScripture
tested four sources. Tier 2 means "Scripture AND film", so a language whose text is on the
Faith Comes By Hearing record (au.m names the media it holds), on Scripture Earth, or in a
Door43 translation was scored 1 — "some resource found" — with its own text and the JESUS
Film both in hand. Measured: 602 codes and 2,001 of 12,379 groups move 1 -> 2. Tier 0 does
not move at all, 1,592 before and after, so nothing about who has NOTHING changes: the gap
lists, the 369 zero-access groups and the bridge-reach table are untouched.
THE SAME BUG DOWNSTREAM, and this is the one a catalyst would have felt: resourceRows typed
an FCBH record "audio, text, video" as Audio Scripture only, so the access table's
byType.Scripture never saw it. 288 people groups were published as "watch or hear, cannot
read" while their own readable Scripture sat behind that link. Access now reads 1,129 "read
and watch" (was 869), 518 "cannot read" (was 806), 85 "read" (was 57), 369 nothing found and
6 stories only — unchanged where it should be, and 2,107 in total either way. Typing the row
by its text would have dropped "can hear", so the access builder now counts a Scripture row
whose scope names audio as hearable too.
ONE OWNER NOW. hasReadableScripture is exported from gospel-resource-rows.js and imported by
the pin builder and by check-gospel-coverage-consistent, whose arm F had its own narrow copy
and therefore reported 2,001 disagreements against the corrected tier — a gate defending the
bug it exists to catch. A rule with four copies has no owner; this one has.
`sx` ships alongside: the readable text with its source named, for the 887 codes whose text is
not at c.s, so a surface can LINK what the tier now counts instead of claiming Scripture and
showing a film. Wiring it into the sheet and the field card is the next commit; this one is
data and rules only, and public/ is deliberately NOT rebuilt because rega is rendering this
worktree.
Second failure on the same feature, and the cause was timing rather than values: the sheet
mounted on cardMode ALONE, so it read selected.country before the shard fetch had set it.
My previous fix put the right value in the right place and left it arriving too late.
The sheet now appears when there is DATA — v-else-if="selected || showGapList", with cardMode
removed from that condition entirely, because a card that has arrived sets both. A wait box
stands in until then and shows the error if the shard 404s, so a loading card looks like one
and a failed card says so instead of showing nothing.
And the card now carries the BRIDGE's own links. In card mode the pin index is never fetched,
so bridgeResources() found nothing and a tier-0 card would have named a way in with no way to
follow it — the single most important thing on that group's card. Derived in the builder
exactly as the leaf derives it, FCBH text fallback included, because a group's readable
Scripture is sometimes only on the audio record. Verified in the data: abai-sungai's card
carries Indonesian with its Scripture, film and Zume links.
NOT LANDING THIS until rega has rendered it on the branch. I have now shipped this feature
blank twice on checks that passed, and the missing check was always the same one: that it
renders. I cannot run a browser, so the claim is not mine to make.
rega found ?card= throwing "Cannot read properties of null (reading 'country')" at the back
button. Card mode had no `selected` — the country — and the sheet reads selected.* in
FOURTEEN places, so guarding the one line rega pointed at would have left thirteen. The card
already knows its country, so `selected` is populated from it and every existing read is
satisfied; the curated-analysis block stays hidden on its own hasCurated test because a card
carries none of those fields. The back button is also hidden in card mode: it would have
opened a country sheet with no pins behind it.
The lesson is mine and worth the line. I shipped this having measured the shards, the byte
saving, the addressing and the card contents — 400 slugs resolving, a tier-0 and a tier-2
card correct — and reported it as done. Every one of those checks passed on a feature that
rendered nothing, because I cannot launch a browser and did not say that the render was
therefore unverified. Data being right is not the feature working.
So the gate grows the arm that would have caught it: a headless mount of ?card=<slug> from
the roster, asserting the page renders more than 400 characters and names the group, plus an
unknown slug that must still render. rega runs it (browser gates are rega's), which is
exactly why it belongs in the gate rather than in my own ad-hoc runs.
BUILD-FIELD-RESOURCE-CARD. For the catalyst standing with the group on a phone. Seeing ONE
group used to cost the engine, the world boundaries, the basemap tiles and the 2.3 MB pin
index before a single link appeared.
?card=<slug> renders the group's sheet alone — no engine, no boundaries, no tiles, no pin
index. Measured from the served files: the map transfers 7,942 KB plus a ~700 KB engine and
unbounded tiles; the card transfers 678 KB worst case, of which 661 KB is the bundle itself
and 17 KB the largest shard. 92% fewer bytes before tiles are counted at all. The bundle is
now the floor, and splitting it is a separate job I have not done.
SHARDED BY A STABLE HASH, after two measured failures: first two letters of the slug gave a
120 KB worst shard because every "Deaf <people>" lands in "de"; three letters left 110 KB
because those slugs all begin "dea". djb2 low byte gives 255 even shards, mean 9 KB, max
17 KB, and the leaf recomputes the key so there is no index and one request. The identical
function lives in both files: if either drifts the card 404s rather than serving somebody
else's group.
Flat filenames, card-<key>.json, because internal/generate-tree.mjs stages tables/*.json as
files and throws EISDIR on a subdirectory — shared build machinery, not mine to change for
one plugin.
Share uses navigator.share where it exists (it offers whatever the catalyst already has) and
falls back to the clipboard, with a cancelled share treated as the non-event it is. The link
carries doxa.life's own slug, so what arrives reopens this card rather than a search — the
slug now reaches the sheet from a tapped pin too, so sharing works from the map as well.
Honesty unchanged: 1,738 cards carry something in the group's own language, 369 carry
nothing and say so with the way in. Checked 400 roster rows resolve to a card, 0 missing;
a tier-0 and a tier-2 card both carry what they should.
rega measured it at ?lang=ar: ".of 5,067 languages have…" and ".both key-gated" — English
runs inside an rtl block, so the browser moves their leading and trailing punctuation to
the wrong end. Thirty of them across four leaves, found by walking the template and
flagging every static English run with no dir anywhere in its ancestry.
Each run is wrapped in <bdi dir="ltr"> rather than giving the block a direction: these
paragraphs mix English prose with translated labels and numbers, and a dir on the
container would left-align the Arabic beside it. bdi isolates exactly the run and nothing
else.
The first pass broke the build and the second caught it: my tag regex ended a tag at the
first ">", so v-if="matches.length > 8" looked like text and the wrapper landed INSIDE the
attribute — v-if="matches.length > <bdi dir="ltr">8". check:sfc-parse failed, I patched
four sites by hand, and that left orphaned </bdi> closes. Reverting all four files and
redoing it with a quote-aware tokenizer was the cheaper fix than repairing my own repair:
30 runs, every open matched, 0 wrappers inside an attribute, SFC-PARSE and gates:pre 11/11
green.
Needs eyes: this is a bidi rendering fix and only a screenshot can confirm the punctuation
sits right. rega has the case at l17-7a7ca67b.
The Driver: a public plugin that is not yet a production map shows under Experimental until it is. A
profile's .meta.json declares "stage": "production" | "experimental" (default experimental; a bundle is
production if any profile says so) and "heavy": true for a live WebGL owner. generate-tree carries both into
manifest.json, so the Studio and the gallery read the same field and neither keeps a list.
The seven production bundles are marked: dashboard-plus-grid, research-map-plus-grid, regions-dashboard,
my-upg-100-list, doxa-simple-map, cities-internet, gospel-resources. The Studio rail keeps its capability
sections for them and puts every experimental bundle (gospel-internet among them) in one final Experimental
section. The gallery's auto-discovered Experimental folder skips a production bundle. gospel-internet-board
joins HEAVY_ELEMENTS (it can own two WebGL contexts). check:studio-rail asserts the split.
The folded explainer justifies showing a COUNT per country rather than a percentage with
"106 of these 175 countries hold one or two groups". Audited today against the roster:
both exactly right. They were also typed in, which is how every stale claim I have fixed
this flight began, so they are computed from the same pin rows the map draws and the
sentence cannot outlive the data. Renders 106 of these 175, unchanged.
Measured at 390x844: the Gap / Resources toggle rendered 48x26 and 129x26, and the
legend's fold button 316x32. None of them FAILED anything — WCAG 2.5.8 puts the AA floor
at 24x24 — but they are small for a thumb on a map that is mostly drag and pinch, where a
missed tap pans the map instead of doing what you asked. They are 54x44 and 316x44 now,
narrow screens only: on a desktop they sit in a 290px card beside a pointer and 26px is
the right density. The legend grows 124px to 154px of an 844px screen, which it can afford.
TWO MISTAKES WORTH RECORDING, both mine, both caught by measuring rather than by reading:
1. Written above .gm-mode's own rule, the media query changed the font size and nothing
else. A media query adds NO specificity and that rule sets min-height:26px, so the
later plain selector won. Reading the computed style is what told me — min-height
resolved to 26px while my font-size had applied, so the rule was live and merely
losing. It has to come last, and the comment says so.
2. Moving it "to the end" put it after the CSS argument, where it concatenated onto the
style element's own id — so the stylesheet lost the rule and the id became
"@media(...){...}doxa-gospel-map". The build passed: it is valid JavaScript. Only
re-measuring the rendered button showed it, which is the second time today a green
build meant nothing about the thing I had changed.
Still 32x32 on a phone: the five .mcb toolbar buttons, which are the shared library
control and every map's, not this leaf's. Reported rather than patched here — one leaf
quietly disagreeing with the fleet about control size is worse than the size.
