docs(i18n): resolve checklist category keys and retain system-key gap

This commit is contained in:
cesnimda
2026-11-02 21:53:58 +01:00
parent 4939585fb1
commit 1559697eda
+10
View File
@@ -0,0 +1,10 @@
# Checklist dynamic translation review — 2026-11-02
Supplement to the historical dynamic inventory; no application behavior changed.
- RESOLVED: `ApplicationChecklist.tsx:207`, `t(keys[category])`. The local map at lines 200–206 contains five literal keys: checklistCategoryPreparation, checklistCategorySubmission, checklistCategoryFollowUp, checklistCategoryInterview, checklistCategoryCustom. Both English (translations.ts:3042–3046) and Bokmål (6163–6167) define all five. The component obtains `t` from useI18n at line 25 and passes it to the category helper. Unknown categories remain user/domain data displayed verbatim; they never become translation keys.
- OPEN: the two checklist-item template calls at lines 214–215 and the two next-step calls in ApplicationWorkspacePage at lines 392/395. `checklistSystemTranslationToken` (applicationWorkspace.ts:94) excludes empty and learning-prefixed keys but otherwise converts arbitrary kebab-case strings. It does not restrict the input to the known translated system items. Catalogue entries alone cannot prove all provider/backend inputs are covered. Inspect the backend system-key producer and compatibility contract before declaring these four calls resolved or changing the fallback.
Reconciled progress: historical inventory has 188 dynamic calls, 108 previously resolved and 80 pending. This supplemental review resolves one additional call: 109 resolved, 79 pending. The original inventory remains a historical source-bound snapshot; do not add this result to a rerun total or label all translation contexts accepted.
Evidence: graph query located ApplicationChecklist, useI18n, applicationWorkspace and ApplicationWorkspacePage; direct source review confirmed the map, translator ownership, token behavior and ten catalogue definitions. Static review only; no runtime coverage claim.