🏠 Overview › 🎯 Features ›🎯 Custom Terminology

Custom Terminology

Feature Detail

medium complexity extracted Organization Management Confidence: 100%
3
Components
4
Shared
0
User Stories
Yes
Analyzed

Description

Custom Terminology enables each organization to override platform-wide display labels with their own preferred vocabulary, ensuring the application feels native to each organization's culture and existing workflows. Admins remap terms such as 'Contact', 'Peer Mentor', and 'Coordinator' to organization-specific equivalents like 'Familie' or 'Bruker'. Overrides are persisted as tenant configuration, delivered via the session bootstrap response, and cached by mobile clients for offline use.

Sources & reasoning

Line 307 makes the labels system a stated mobile architecture requirement fetched at startup and cached offline. Line 244 positions it as one of the three tenant-behaviour mechanisms alongside module toggles. Phase 1 admin scope (line 327) explicitly includes 'terminologikonfigurasjon', confirming MVP classification.

  • docs/source/likeperson.md · line 307
    Organization labels system - per-org terminology overrides fetched from backend and cached offline (currently: contacts, my_contacts, peer_mentors; extensible to singular forms and role terms such as peer_mentor, coordinator, contact)
  • docs/source/likeperson.md · line 244
    terminology/labels system for display strings
  • docs/source/likeperson.md · line 327-328
    Organisasjonsinnstillinger og terminologikonfigurasjon

Analysis

Business Value

Different member organizations use fundamentally different vocabulary for the same roles and relationships - Barnekreftforeningen speaks of families rather than contacts; HLF has regulatory terminology around certification. A rigid platform vocabulary creates cognitive friction and adoption resistance. Custom terminology removes this barrier by letting each organization present the platform in its own voice, reducing training overhead and supporting the design principle of lowest possible cognitive load stated in §1. Downstream, it also prevents support tickets caused by unfamiliar labels confusing end users.

Implementation Notes

Terminology overrides are stored in the terminology_overrides table (many-to-one with organizations). The REST API includes the active override map in the session bootstrap response so clients receive it at login without an extra round-trip. The mobile app caches overrides in the local Drift database for offline access. The admin UI provides a key-value editor listing all overrideable keys with their current and default values. Validation enforces non-empty strings within defined length limits. Resetting a key removes its override record and the platform default is used instead.

Components (7)

User Interface (1)

ui TerminologyEditorPage medium

Service Layer (1)

service TerminologyService medium

Data Layer (1)

data TerminologyRepository medium

Shared Components

These components are reused across multiple features

User Stories

No user stories have been generated for this feature yet.