Opened 3 years ago
Last modified 3 years ago
#54761 new enhancement
Save the prefered language from login page (since WP5.9)
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.9 |
Component: | Login and Registration | Keywords: | 2nd-opinion early has-patch needs-testing |
Focuses: | administration | Cc: |
Description
Hello,
On WP5.9 a language switcher is added in the wp-login.php. Here is the dev note by @audrasjb https://make.wordpress.org/core/2021/12/20/introducing-new-language-switcher-on-the-login-screen-in-wp-5-9/
I think it should be great if choosing a language here will update the Language user meta to display the back-office in the same language as previously chosen.
As per 1st test made, this doesn't currently update.
Attachments (1)
Change History (14)
#2
@
3 years ago
Yes, good idea to collect feedbacks.
In my mind it's logical, I select a language to log in... why once logged in I have another language served ?
That's not because others do something, it's the truth (IMO).
#3
@
3 years ago
I hadn't seen that this choice was limited to the login page, and I really wonder about the logic behind such a choice: who wants to specify a language for the login page and stay in another on the administration?
This is not a criticism but a question :)
As a user, if I change the language, I want it to be used everywhere. My multilingual clients too. Otherwise I will have to deactivate this option because they will not understand it.
#4
@
3 years ago
who wants to specify a language for the login page and stay in another on the administration?
That‘s not the idea behind this.
Let‘s say my user language here on WordPress.org is Spanish.
I want to log in, but the login page is in English, so I change the language there to Spanish so I better understand it.
Now, it could be that I don‘t really want to change the language on the login page since it’s just two form fields that I am familiar with, so I leave it in English.
So I log in regardless.
My user language in the admin should still be Spanish.
I hope this little example shows that this ticket isn‘t as straightforward as one might think.
#5
@
3 years ago
I agree with you @swissspidy.
If the Spanish is set in the user profile, and we chose the Spanish in the login page, we do not change anything.
We'll just change the user profile if the language stored in the meta is different from the language selected on the login page.
#6
@
3 years ago
In my opinion, changing the language on the login page should have an impact to back-office too (for the entire session). Otherwise what's the point of this option? Only for translate fields on login page?
#7
@
3 years ago
- Milestone changed from Awaiting Review to 6.0
We'll just change the user profile if the language stored in the meta is different from the language selected on the login page.
If you mean the usermeta
, this won't address @swissspidy's point. See these results.
Instead, we would need to change the user profile if the site's language is different from the language selected on the login page. See these results.
Note: With this implementation, if a user wants to switch back to the site's language, they would need to make the change in their profile.
In general, matching a user's stated preference to their usermeta makes sense to me.
Milestoning for 6.0
and adding needs-unit-tests
to prevent regressions once this has been implemented.
#8
@
3 years ago
Hello,
I can try to write a patch for this but in which Core file do you think it should be the more relevant ?
Thank you for your help.
#9
@
3 years ago
Hello,
In my mind, we have 4 cases, but I can miss some...
Site_lang === Profile_lang ===login_lang => return, nothing to do Site_lang === Profile_lang !==login_lang => update Profile_lang Site_lang !== Profile_lang ===login_lang => return, nothing to do (Site_lang !== Profile_lang !==login_lang => update Profile_lang)
Do I miss some cases ?
#10
@
3 years ago
Hi @sebastienserre,
The first three cases are accurate, but the fourth is incorrect IMO. We should not update Profile_lang in the fourth case.
See @swissspidy's example case for the expected behaviour and these results for how this can be achieved.
@
3 years ago
Cookie based we can change user_meta locate when user select language before the login.
This ticket was mentioned in Slack in #core by costdev. View the logs.
3 years ago
#13
@
3 years ago
- Keywords early has-patch needs-testing added; needs-patch removed
- Milestone changed from 6.0 to Future Release
Per the discussion in the bug scrub, I'm moving this to Future Release and marking as early
as this still needs discussion.
Also adding has-patch
and needs-testing
.
There are currently two approaches:
- Using cookies in 54761.patch. However, as noted in the bug scrub:
@joedolson What if the cookie is set from a previous log-in, and the user changed their login_lang in the admin? E.g., when they logged-in they chose German; but in the admin they changed to Dutch. What happens on their next log-in?
- Based on these tests, conditionally applying the user language.
Some thoughts:
- Using the cookie is not reliable.
- The cookie may have been stored by a previous user.
- When a user logs out,
$_GET['wp_lang']
is set to that user's locale. This in turn sets the cookie. So if one logs out to let the other log in, the second user's language would change.
- Using
$_GET['wp_lang']
by itself is not reliable.- The user may have been sent a link with
?wp_lang=en_US
, for example. - When a user logs out,
$_GET['wp_lang']
is set to that user's locale. So if one logs out to let the other log in, the second user's language would change. - This applies to any
$_GET[]
-only or$_GET[] + cookie
solution. They are not reliable.
- The user may have been sent a link with
- We cannot assume that visiting a page implies intent to change language.
- We can only assume intent by the user actually clicking the "Change" button.
- We cannot rely upon Javascript solutions.
If others agree with the above, once we determine the best way to detect that the user has clicked the "Change" button, we can put this code (or similar) at or near line 1294:
<?php if ( is_a( $user, 'WP_User' ) && $user->exists() && $user_has_clicked_change ) { /* * Since it has been verified that the user has clicked the "Change" button, * and clicking the button also sets $_GET['wp_lang'], this can now be used * with some confidence. */ $wp_lang = sanitize_text_field( $_GET['wp_lang'] ); // This condition matches the one here: https://3v4l.org/p8gRv if ( get_locale() !== $wp_lang && get_user_locale() !== $wp_lang ) { update_user_meta( $user->ID, 'locale', $wp_lang ); } }
Interesting idea! Personally, for me as a user that would be a bit unexpected. For example Facebook does not do this either.
It would be good to collect some user feedback on this and compare with other platforms.