[Backend] Support for Language Translations (English / Turkish)

[delos0]

[Backend] Support for Language Translations (English / Turkish)

Parent issue: #TBD

Description

Implement backend support for the language preference feature in MapCess. The Spring Boot backend must expose API endpoints to store and retrieve each user's chosen interface language, so that the preference persists across sessions and devices.

Feature / Task Details

• Add a language field to the user profile model (allowed values: en, tr, ar; default: en)
• Implement REST endpoints:
  • GET /api/users/{id}/preferences/language — retrieve the authenticated user's language preference
  • PUT /api/users/{id}/preferences/language — update the authenticated user's language preference
• Alternatively, extend the existing accessibility preferences endpoint to include language in the same payload (coordinate with frontend/mobile teams)
• Secure endpoints: authenticated users may only access their own preference
• Return the language preference as part of the user profile response on login (to minimise extra round-trips on app startup)
• Write unit and integration tests for new endpoints

Deliverables

• Database migration to add language column to user profile
• REST endpoints for GET and PUT language preference
• Language preference included in the login/profile response payload
• Unit and integration tests

Acceptance Criteria

• GET /api/users/{id}/preferences/language returns the user's current language preference
• PUT /api/users/{id}/preferences/language updates and persists the preference
• Endpoints are secured — users cannot access other users' preferences
• Language preference is returned in the user profile/login response
• Invalid locale values are rejected with a 400 error
• Unit and integration tests written and passing
• API documented (Swagger/OpenAPI updated)
• Documentation updated (if applicable)

Deadline

01.05.2026

Notes

Agree on the API contract with the web and mobile teams before implementation. If the accessibility preferences endpoint already exists (see issue #289), consider extending it to include language rather than creating a separate endpoint, to keep the API surface minimal.