Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#54761 new enhancement

Save the prefered language from login page (since WP5.9)

Reported by: sebastienserre's profile sebastienserre 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)

54761.patch (786 bytes) - added by ravipatel 3 years ago.
Cookie based we can change user_meta locate when user select language before the login.

Download all attachments as: .zip

Change History (14)

#1 @swissspidy
3 years ago

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.

#2 @sebastienserre
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 @Webaxones
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 @swissspidy
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 @sebastienserre
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 @uzumymw
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 @costdev
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 @sebastienserre
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 @sebastienserre
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 ?

Last edited 3 years ago by sebastienserre (previous) (diff)

#10 @costdev
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.

Last edited 3 years ago by costdev (previous) (diff)

#11 @ocean90
3 years ago

#55002 was marked as a duplicate.

@ravipatel
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 @costdev
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?


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.
  • 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 );
        }
}
Note: See TracTickets for help on using tickets.