User Language Preference in Profile (Override Accept-Language Header)

[kevalyq]

📝 Description

Allow users to set their preferred language in their profile, which overrides the browser's Accept-Language header. This gives users explicit control over the application language regardless of their browser settings.

🎯 User Story

As a user, I want to set my preferred language in my profile settings, so that I can use SecPal in my language of choice even when my browser is configured for a different language.

💡 Proposed Solution

Locale Priority Order

1. User Profile Setting (highest priority) - if user has explicitly set a language preference
2. Accept-Language Header (fallback) - browser preference
3. Application Default (en) - if neither is available

Implementation Steps

1. Add preferred_locale column to users table (nullable, default: null)

   • Values: en, de, or null (use Accept-Language)

2. Update Locale Middleware to check user preference first:

   $locale = $request->user()?->preferred_locale 
             ?? $request->getPreferredLanguage(['en', 'de'])
             ?? 'en';

3. Add API endpoint to update user language preference:

   • PATCH /api/v1/me/language with body { "locale": "de" }

4. Frontend: Add language selector in user profile/settings

✅ Acceptance Criteria

• User can set preferred_locale in their profile
• User's explicit language choice overrides Accept-Language header
• Setting preferred_locale to null falls back to Accept-Language
• API endpoint validates locale values (only en, de allowed)
• Tests verify priority order: user preference > header > default
• Migration is reversible
• Documentation updated

🔗 Dependencies

• Depends on: PR-1: API Translation.io Integration & Configuration #84 (API Translation.io Integration must be complete)
• Depends on: TBD (Middleware implementation for Accept-Language)
• Related: [EPIC] Multi-Language Support with Translation.io #83 (Epic: Multi-Language Support)

📚 Technical Notes

• Store as 2-character locale code (en, de)
• Column type: VARCHAR(5) (allows future expansion to en-US, de-DE)
• Add validation rule: in:en,de or nullable
• Consider adding index on preferred_locale if we need to query by language in future

🚫 Non-Goals

• Automatic detection based on IP/location (not in scope)
• Language switching without authentication (guests always use Accept-Language)
• Per-tenant language settings (tenant admins can't force language for all users)

---

Priority: Medium (enhancement after basic i18n is working)
Effort: Small (~2-4 hours including tests)

[github-actions]

✅ This issue has been added to the SecPal Feature Roadmap with status: 💡 Ideas

New idea - needs discussion and evaluation

Status Flow:
💡 Ideas → 💬 Discussion → 📥 Backlog → 📋 Planned → 🚧 In Progress → 👀 In Review → ✅ Done

Note: Ideas that won't be implemented should be moved to 🚫 Won't Do with a reason.