03839179b7
The legend's region sections, its Deaf row and its one-country zones, the wall's card names, the print progress and error messages, the map's status badge and the Population column all rendered English in every locale. None of them was visible to check:hardcoded-english: they were single words, .js modules, Error() arguments, library components or number formatting. - Legend: region rows through one REGION_KEY table shared with the wall (poster.region_*, new region_deaf); zones through zoneTitle (tier A by country, the Deaf row by its bloc name); node ids stay English-derived. - Wall: card labels through zoneTitle, so the Show-on-map name, alt text, tooltip, HUD title and printed title agree with the legend and packet. - Errors a reader sees are keyedError(key, English, params); errorText(e, t) shows them translated, and an unkeyed error still shows its own message. Developer detail for a failed data load goes to the console; the badge says upgMap.mapDataFailed. - Population: Intl compact notation in the app's locale, same precision. - Country Posters: the unsupported card's reason is messages.countryPosterTooMany, not the data file's English note. - Strings only the UPG-100 map shows move to a new upgMap area, so other bundles do not carry them (country-posters 1,490,907 bytes). - check:hardcoded-english judges keyedError's English as a fallback (quiet when the key resolves everywhere, a finding when it does not); check:label-key-coverage follows REGION_KEY to legend-tree.js and covers the legend's table and its regionFor producer. Both self-tests two-sided.
1.9 KiB
Locale catalogues (locales/)
This note sits beside locales/, not in it: several gates and the build read every entry in
that folder as a locale.
One folder per locale, one JSON file per top-level area. SUPPORTED_LOCALES in
library/i18n/index.js is the list the runtime will actually try to resolve; the folders
here are what happens to exist on disk. A missing area file is fine — those namespaces
resolve through fallbackLocale: 'en'.
Nothing in these files is a comment. Every string ships to every reader of that locale,
so notes about the catalogue belong here, not in a _note key. An English _note inside
ar/gospel.json was downloaded by every Arabic reader and — because it was text present in
ar and absent from en — it also satisfied a gate probing for "does this bundle contain
Arabic translations?", hiding the fact that every Arabic character had been stripped. A
value that no reader is meant to see is a value no check should be able to count.
gospel.json holds SHORT UI LABELS ONLY
The explanatory prose on the gospel-resources surfaces stays in English on purpose and is
not in this area. It carries doctrinal and statistical precision — which pools were
searched, what "nothing found" does and does not claim, why Open Bible Stories is not
Scripture — and a mistranslated caveat there would read as authoritative. gospel.prose.english
is the one translated line that says so.
When a human-reviewed translation of that prose exists, it gets its own area file and that line comes out.
upgMap.json holds strings only the UPG-100 map shows
A bundle carries an area when its code names it (internal/i18n-areas.mjs), so strings that only one
plugin shows belong in an area of their own rather than in messages, which every bundle carries.
upgMap is that area for the UPG-100 map's selection and data-failure messages: 11 locales × those keys
stay out of country-posters, which sits just under the bundle size ceiling.