Category names not translated — display in English on the French UI

## What happens With the UI set to French (`Vos intérêts`, `Choisissez 3 à 5 sujets pour personnaliser votre fil`, `Enregistrer`, `5 sur 5 sélectionnées`), the **category labels themselves stay in English**: - *Social & Networking* - *Sports & Outdoors* - *Music & Arts* - *Tech & Science* - *Food & Drinks* - *Health & Wellness* - *Education & Learning* - *Games & Hobbies* - *Community & Causes* - *Business & Career* - *Language & Culture* - *Family & Parenting* This breaks the localized experience for the very feature whose job is *"choisissez 3 à 5 sujets pour personnaliser votre fil"* — picking topics. Half the page is in French, the topics are in English. ## Where the bug appears The screenshot shows the onboarding **interests** picker (`Vos intérêts`), but the same untranslated category labels likely show up wherever categories are listed: - Onboarding Step 2 (Pick your interests). - Profile → Preferences (interests edit). - Event detail page (category pills under the title). - Group / org public profile (category pills). - Discover / Explore filters. - Search results (category facet). - Organization settings → Categories section. Fix at the source so every surface gets translations for free. ## Reproduction 1. Set the UI language to French (header → FR, or sign in as a user whose locale is `fr`). 2. Navigate to the interests picker (onboarding Step 2 or Profile → Preferences → Interests). 3. Observe: every category card displays its English name. ## Likely root cause Categories are almost certainly stored with a single-locale `name` column in the database (or a fixed-string enum), and the UI renders that column verbatim. There's no `name_en` / `name_fr` lookup, no i18n key per category, no translation table. Fix direction: ### Option A — translation table on the backend (recommended) Add a `category_translation` table with `(category_id, locale, name)` rows. Each category has one row per supported locale. Backend's category-list endpoint returns either the locale-aware label (when the user has a locale) or a `translations` map the frontend picks from. - Pros: scales to N locales without code changes; easy to add new locales (insert rows). - Cons: needs a small backfill migration to populate French translations for existing categories. ### Option B — i18n keys per category in the frontend Backend keeps returning the English name as a stable identifier (or returns a `slug`). Frontend has `categories.<slug>.name` keys in `en.json` and `fr.json` and looks up via `t('categories.' + category.slug + '.name')`. - Pros: lighter migration — no DB change. - Cons: every new category requires a frontend deploy AND a backend insert; categories become a coupled-deploy concern. Option A is more robust long-term; Option B is the quicker patch. ## Secondary observation (small, separate) The screenshot shows **two count lines** stacked at the bottom: `5 sur 5 sélectionnées` and `5 sur 5 sélectionnés`. Same value, two different gender agreements (fem vs masc) — looks like two separate i18n keys both rendering at the same time. Probably one is leftover and should be removed, or two components are both rendering the count. Worth checking when fixing this bug — likely a quick same-MR cleanup. ## Impact - Localized experience is broken at the most personalization-relevant moment (picking interests). - Trust signal: a French speaker sees that the team "says" they support French but only halfway. That undermines the value proposition. - Discovery / search filters are also in English — French users may not realize a category they want to pick exists at all. ## Found by Manual testing in French locale