# 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 `en` and `fr`.
- Remove tier `Name` and `Description` from the base tier model.
- Select tier translation from `Accept-Language`, fallback to English.
- Send the active frontend locale as `Accept-Language` on API requests.
- Regenerate EF migration, OpenAPI, and frontend schema.
- Audit similar database-backed display strings that are currently unlocalized.

## Validation

```bash
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

- [x] Tier display names and descriptions are stored per culture.
- [x] Tier APIs return localized `name` and `description`.
- [x] English is used when the requested locale is missing.
- [x] Frontend API requests include the current locale.
- [x] Similar unlocalized persisted display strings are identified.

## Localization Audit

- Calendar catalog seed rows still store curated `Title` and `Description` as 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`, and `Description` fields 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.