[wp-trac] [WordPress Trac] #54761: Save the prefered language from login page (since WP5.9)

[WordPress Trac]

#54761: Save the prefered language from login page (since WP5.9)
-------------------------------------------------+-------------------------
 Reporter:  sebastienserre                       |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Login and Registration               |     Version:  5.9
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion early has-patch needs-   |     Focuses:
  testing                                        |  administration
-------------------------------------------------+-------------------------
Changes (by costdev):

 * keywords:  needs-patch 2nd-opinion => 2nd-opinion early has-patch needs-
     testing
 * milestone:  6.0 => Future Release


Comment:

 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
 [https://core.trac.wordpress.org/attachment/ticket/54761/54761.patch
 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 [https://3v4l.org/p8gRv 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.
 - 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) [https://core.trac.wordpress.org/browser/tags/5.9/src/wp-
 login.php#L1294 at or near line 1294]:

 {{{#!php
 <?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 );
         }
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54761#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform