Sync UI language selection with user profile settings#14151
Sync UI language selection with user profile settings#14151
Conversation
There was a problem hiding this comment.
Code Review
This pull request implements a user language preference system by introducing a new ProfileLanguageMiddleware, updating the profile form and admin interface, and adding a view to handle language selection. Feedback focuses on ensuring the user profile remains the source of truth for language settings, avoiding constant duplication, and persisting language changes to the database for authenticated users.
| lang = request.session.get(SESSION_LANG_KEY) | ||
|
|
||
| if not lang: | ||
| lang = getattr(request.user, "language", None) | ||
| if lang: | ||
| request.session[SESSION_LANG_KEY] = lang |
There was a problem hiding this comment.
The current logic prioritizes the session value even if the user's profile language has been updated (e.g., via the profile edit form). For authenticated users, the profile should be the source of truth to ensure consistency across the application. Additionally, this suggestion avoids redundant session writes by only updating the session if the value has actually changed.
| lang = request.session.get(SESSION_LANG_KEY) | |
| if not lang: | |
| lang = getattr(request.user, "language", None) | |
| if lang: | |
| request.session[SESSION_LANG_KEY] = lang | |
| lang = getattr(request.user, "language", None) | |
| if lang and request.session.get(SESSION_LANG_KEY) != lang: | |
| request.session[SESSION_LANG_KEY] = lang |
There was a problem hiding this comment.
The proposed change would re-sync the session from the DB on every request and undo user language changes from the UI, so I’m keeping the current logic
| return qs | ||
|
|
||
|
|
||
| SESSION_LANG_KEY = "language_override" |
There was a problem hiding this comment.
| if lang_code and check_for_language(lang_code): | ||
| request.session[SESSION_LANG_KEY] = lang_code |
There was a problem hiding this comment.
To fully synchronize the UI language selection with the user profile as intended, the selected language should be persisted to the user's profile when they are authenticated. This ensures the preference is preserved across different sessions and devices.
| if lang_code and check_for_language(lang_code): | |
| request.session[SESSION_LANG_KEY] = lang_code | |
| if lang_code and check_for_language(lang_code): | |
| request.session[SESSION_LANG_KEY] = lang_code | |
| if request.user.is_authenticated: | |
| request.user.language = lang_code | |
| request.user.save(update_fields=["language"]) |
There was a problem hiding this comment.
This would change the semantics of the topbar switcher from a session-only override to a persistent profile update. So I will keep the current approach.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #14151 +/- ##
===========================================
- Coverage 74.62% 52.59% -22.03%
===========================================
Files 958 958
Lines 57891 58110 +219
Branches 7889 7930 +41
===========================================
- Hits 43202 30564 -12638
- Misses 12927 26103 +13176
+ Partials 1762 1443 -319 🚀 New features to boost your workflow:
|
| ) | ||
|
|
||
| # This setting includes supported Maptstore language choices in a DB-based format | ||
| PROFILE_LANGUAGE_CHOICES = tuple((code.split("-")[0].lower(), label) for code, label in MAPSTORE_DEFAULT_LANGUAGES) |
There was a problem hiding this comment.
can't we use the get_2letters_languages utils with some changes?
There was a problem hiding this comment.
@mattiagiupponi thanks for the comment. Ini my opinion, the idea in this setting is to completely be synced with the Mapstore supported languages. I'm afraid that if we use / modify this method, we will add a bit of complexity and it will not such clear that the source of truth here is the supported Mapstore language.
This PR was created according to this issue: #14150
Checklist
For all pull requests:
The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):
Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.