See Organization-Specific Terminology on the Selection Screen
Each organization participating in the platform uses different terminology. For example, NHF may call the peer helper role 'likeperson' while another organization uses 'frivillig' or 'støtteperson'. The terminology-aware text widget (679-terminology-aware-text-widget) and organization labels provider (006-org-labels-provider, 199-org-labels-provider) dynamically resolve label keys to organization-specific strings. On the org selection screen, the role label displayed under each organization card must reflect that organization's configured terminology, not a generic default. This requires loading org-specific label configurations before or alongside the org list.
User Story
Audience Summaries
Displaying correct organization-specific terminology on the very first screen users encounter after login is a direct trust signal. Each pilot organization — NHF, Blindeforbundet, HLF, and Barnekreftforeningen — has invested in building a distinct identity around its peer support model, including unique vocabulary for roles like peer helpers and coordinators. When the platform reflects that vocabulary immediately, it signals to volunteers and coordinators that the app was built for them, not repurposed from a generic tool. This reduces early-session abandonment, strengthens organizational buy-in during the pilot, and increases the probability that each organization renews and expands its commitment post-pilot.
Terminology alignment is low-cost to implement but high-impact on perceived product quality and organizational fit.
This story depends on story-organization-selection-screen-peer-mentor-001 and requires coordination between the org labels provider components (006 and 199) and the terminology-aware text widget (679). The primary delivery risk is ensuring label configurations are loaded before or in parallel with the organization list fetch — a timing dependency that requires careful async sequencing. Acceptance criteria include four distinct test scenarios covering multi-org users, custom label display, fallback behavior when data is unavailable, and session-wide terminology propagation after org selection. Testing must cover at least the four pilot organizations with their actual label configurations.
Rollout should include a configuration validation step to confirm all pilot orgs have label data populated before launch.
Implementation requires the org selection screen to fetch and resolve label configurations per organization before rendering each org card. The org labels providers (006-org-labels-provider, 199-org-labels-provider) must be invoked with per-org context, not a single global context. The terminology-aware text widget (679-terminology-aware-text-widget) should receive the correct label key and org-scoped resolver. Edge cases include: labels not yet loaded at render time (requires a fallback string and loading state), orgs with no custom label configured (must gracefully default without crashing), and ensuring the selected org's full terminology set is propagated into session state so downstream screens use the same resolved labels.
Unit tests should mock the label provider for each pilot org and assert correct label resolution per card.
Acceptance Criteria
- Given I belong to two organizations with different terminology configurations, When the org selection screen loads, Then each organization card displays the role label using that organization's own terminology
- Given an organization has a custom label configured for 'peer mentor', When I view that organization's card, Then the role is displayed using the custom label, not a hardcoded default
- Given terminology data is not yet loaded for an organization, When that org's card is rendered, Then a sensible fallback label is shown and the UI does not crash or show a blank role label
- Given the organization labels provider successfully loads configurations, When I select an organization, Then all subsequent screens in the session use that organization's full terminology set
Business Value
Each of the four organizations in the pilot (NHF, Blindeforbundet, HLF, Barnekreftforeningen) uses different vocabulary for peer helpers, coordinators, and activities. Displaying incorrect terminology on the very first screen users encounter after login creates immediate confusion and erodes trust in the platform. Correct terminology at the org selection step reinforces that the app understands each organization's identity and prepares the user for a contextually appropriate experience throughout their session.
Components
- Organization Labels Provider infrastructure
- Organization Labels Provider infrastructure
- Terminology-Aware Text Widget ui
- Organization Labels Notifier service
- Label Key Resolver Service service
- Terminology Sync Service service
- Terminology Repository data
- Terminology Local Cache Adapter data
- Label Key Registry infrastructure
- Terminology Riverpod Providers infrastructure
- WCAG Semantics Label Resolver infrastructure