b4a0387495
Measured under ?lang=ru on both composites: every Latin-script string left on the
page was ours. The map above was fully translated; underneath it the grid, the
map's own side menu and filter panel, and the whole research dashboard were
English in Arabic, Chinese, Hindi, Russian and everything else.
Three surfaces, three reasons, none of them a missing translation:
the grid read labels from a host-supplied `t` object that nothing ever
filled, with an English literal at each call site as fallback
side menu +
filter panel plain string literals
dashboard labels declared as literals in dashboard.config.js — facet
rail, chart titles, KPI strip, table headers, segmented
control, search placeholder
New catalogues for all 11 locales (grid, controls, dashboard), REUSING the
catalogue's existing wording wherever the word already existed — Регион, Блок
родства, Население, Вовлечён, Графики — so two panels never name one thing two
ways, and nothing is coined that the project already has a word for.
Read through a new plugin-free tStatic() rather than useI18n, because these
components are also mounted by entries that install no i18n plugin. An unguarded
useI18n() throws and a thrown setup() removes the subtree with no build error —
the defect that had just blanked people-groups-grid everywhere (6603dc17).
★ THE CONFIG LABELS ARE GETTERS, AND A SPREAD WOULD HAVE LOOKED IDENTICAL.
dashboard.config.js is imported once at load; the locale is only known later. My
first version spread a getter object, and a spread COPIES THE RESOLVED VALUE, not
the accessor — every label would have frozen at whichever locale loaded first,
and it would have looked perfect in English. `get label() {…}` resolves on each
read.
MEASURED after, served built tree, identity checked first: Big Picture ru/ar and
Simple Research ru/zh have ZERO Latin-script chrome strings. What remains is
Mapbox's licence attribution (never translate), country and people-group names
(data), and 'UUPGs' — which every locale file deliberately keeps as the acronym.
Three gates went red on the way, two of them mine and worth recording:
check:locale-reachable slices this i18n module between two markers and EVALS
the slice; I had put tStatic between them, so the gate
hit an `export`. Moved to the end of the file.
check:library-index my import+helper above a component's docblock became
that component's DERIVED description. Moved below it.
check:kpi-unit its parser assumed single-brace entries, so getters made
it find ZERO pct KPIs — and it failed rather than
printing a green PASS about nothing, which is the gate
working. Parse now understands getters AND checks the
translated labels, so a '%' reintroduced in any of the
11 catalogues fails by name. Both controls fired.
35 lines
1,002 B
JSON
35 lines
1,002 B
JSON
{
|
|
"bloc": "亲缘板块",
|
|
"gospel_access": "福音可及性",
|
|
"people": "民族",
|
|
"people_name": "民族（名称）",
|
|
"praying": "正在代祷",
|
|
"religion_family": "宗教族系",
|
|
"search_language": "搜索语言",
|
|
"search_people": "搜索民族",
|
|
"search_place": "搜索地点",
|
|
"search_religion": "搜索宗教",
|
|
"upgs_in_scope": "范围内的 UPG",
|
|
"countries_touched": "涉及国家",
|
|
"unreached": "未得之民",
|
|
"sum_population": "Σ 人口",
|
|
"sum_praying": "Σ 代祷",
|
|
"charts": "图表",
|
|
"table": "表格",
|
|
"cluster": "民族群",
|
|
"country": "國家",
|
|
"engagement": "参与",
|
|
"language": "语言",
|
|
"language_family": "语系",
|
|
"people_group": "民族",
|
|
"population": "人口",
|
|
"prayer": "祷告",
|
|
"region": "区域",
|
|
"religion": "宗教",
|
|
"status": "状态",
|
|
"adopted": "已认领",
|
|
"filters": "筛选",
|
|
"gospel_resources": "福音资源",
|
|
"map": "地图",
|
|
"search_placeholder": "搜索民族、地点、语言、宗教…"
|
|
}
|