1.9 KiB
1.9 KiB
Task: Localized organization membership tier display
Feature Spec
docs/FEATURES/organizations.md
Goal
Move membership tier display names and descriptions into localized database rows so API consumers receive tier copy in the requested language with English fallback.
Scope
- Add membership tier translation persistence for
enandfr. - Remove tier
NameandDescriptionfrom the base tier model. - Select tier translation from
Accept-Language, fallback to English. - Send the active frontend locale as
Accept-Languageon API requests. - Regenerate EF migration, OpenAPI, and frontend schema.
- Audit similar database-backed display strings that are currently unlocalized.
Validation
dotnet ef migrations add LocalizeOrganizationMembershipTiers --project backend/src/Socialize.Api/Socialize.Api.csproj --startup-project backend/src/Socialize.Api/Socialize.Api.csproj
dotnet test backend/Socialize.slnx
cd frontend && npm run build
./scripts/update-openapi.sh
Done When
- Tier display names and descriptions are stored per culture.
- Tier APIs return localized
nameanddescription. - English is used when the requested locale is missing.
- Frontend API requests include the current locale.
- Similar unlocalized persisted display strings are identified.
Localization Audit
- Calendar catalog seed rows still store curated
TitleandDescriptionas single-language strings. This looks similar to membership tiers because the copy is product-owned catalog metadata, not user-authored content. - Backend-generated notification/activity messages are persisted as English sentences. They are event history, but they are still user-visible generated copy.
- Most other
Name,Title, andDescriptionfields found in modules are user-authored domain content, imported calendar event data, identifiers, roles, statuses, or test data and should not be translated by the platform.