govoplan-core/docs/LOCALIZATION_AND_HELP_QUALITY.md

Localization And Contextual Help Quality

Reference Language

German (de) is GovOPlaN's first-class reference target. Every translation key used by a shipped WebUI must exist in German and English. German completeness is a release gate; English remains the source-code fallback language so existing literal labels and external developer APIs do not change semantics.

New installations and tenants default to German. Existing system, tenant, and user preferences are preserved. The available-language and policy model can still select another default or disable a package at the relevant scope.

Explicit high-risk help content and browser acceptance are tracked in Core #284.

The platform inventory recognizes both inline locale objects and generated catalogs declared as const de / const en. Its strict mode requires both locales and reports de explicitly as the reference locale.

Structured Documentation Localization

DocumentationTopic.translations continues to own localized title, summary, and body prose. Topics whose metadata contains rendered prose opt into the separate structured_translation_version="1" contract and provide a complete same-shape value for each translated metadata key in structured_translations. Version 1 covers workflow prerequisites, steps, outcome, result and verification; reference fields; limitations, constraints, consequences and consequence classes; and the other rendered explanation fields declared by Core.

The registry rejects an unversioned translation, an unsupported contract version, missing structured keys, changed object keys or list lengths, empty translated strings, and changed non-text values. Stable field IDs, routes, permission scopes, and other technical leaves therefore remain structurally bound to the source metadata. The Docs module overlays only a validated locale at response time and reports the selected structured locale separately from the title/body locale. Missing structured translations fall back to source content and remain visible in public coverage until the owning module adopts the contract.

Help Resolution

Every focusable field and action receives a stable derived F1 identity from the shared shell, even when the component has no dedicated help text. Resolution falls back from field/action to dialog or page and then to the module's visible documentation baseline.

Backend manifests publish explicit topic associations first. Core additionally associates declared route, navigation, settings, and View surface IDs with the module's static user or administrator documentation baseline. Feature modules should still add exact metadata.help_contexts entries for consequential, unfamiliar, policy-controlled, destructive, security-sensitive, or legally meaningful fields and actions.

The shared retention-policy editor exposes explicit contexts for each stored data category, audit-detail control, lower-level override switch, target selector, reload, and save action. The Policy module owns the matching German administrator guidance. Retention execution surfaces use separate contexts for dry-run, destructive apply, confirmation, and outcome review so F1 opens the consequence and recovery guidance closest to the focused control. Shared controls may set helpModuleId when their documentation owner differs from the containing page; the retention editor uses this to resolve Policy help from both administration and Campaign surfaces.

The shared reusable-credential manager keeps Access as its documentation owner and publishes exact contexts for credential kind, secret replacement/removal, module and server restrictions, lower-scope visibility, activation, save, and irreversible deletion. This ensures F1 explains secret custody and the effect on dependent connections from system, tenant, group, user, and personal surfaces.

The source inventory treats literal helpContextId and data-help-context-id declarations as authored help associations, including a native control nested in FormField. Dynamic context expressions remain separate evidence and generic derived fallbacks remain in the richer-help candidate queue.

The generated help_review_candidates list is therefore a content-depth queue, not a list of controls on which F1 cannot work. It should prioritize:

1. effect, deletion, delivery, retention, disclosure, encryption, and recovery;
2. identity, representation, mandate, institutional context, and purpose;
3. valid-time versus recorded-time selection;
4. provider authority, synchronization, conflict, and outcome unknown;
5. fields whose consequences are not evident from their label.

The shared browser conformance journey mounts the production Help menu and resolver. It proves that F1 uses the focused control rather than only the page, maps an exact retention action to Policy-owned administrator documentation, retains the page context as fallback for derived actions, exposes an accessible modal at narrow widths, closes with Escape, and restores focus to the triggering control. Module journeys should add their own exact high-risk mappings; they do not need to reimplement the keyboard or dialog mechanics.

Verification

cd /mnt/DATA/git/govoplan
/mnt/DATA/git/govoplan/.venv/bin/python \
  tools/inventory/platform-interface-inventory.py \
  --strict --strict-declarations --strict-endpoints

The check must report:

• reference locale de present and complete;
• no used key missing from de or en;
• every field has a resolvable F1 context;
• no duplicate stable IDs;
• no undeclared public WebUI surface;
• no stale runtime route or endpoint declaration.

Browser acceptance is part of the focused workspace gate and can be run alone:

cd /mnt/DATA/git/govoplan-core/webui
npm run test:conformance