[wp-trac] [WordPress Trac] #44758: The REST API is not respecting the user's locale properly.

[WordPress Trac]

#44758: The REST API is not respecting the user's locale properly.
-------------------------------------------------+-------------------------
 Reporter:  youknowriad                          |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  REST API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion has-patch has-unit-      |     Focuses:
  tests dev-feedback                             |
-------------------------------------------------+-------------------------
Changes (by TimothyBlynJacobs):

 * keywords:  2nd-opinion => 2nd-opinion has-patch has-unit-tests dev-
               feedback


Comment:

 Uploaded a patch based off what we discussed in the last REST API meeting:
 https://wordpress.slack.com/archives/C02RQC26G/p1535649512000100

 This will switch the locale if the `_locale` query argument is set to
 `user`. The switching happens after auth and is restored after echoing the
 content. If it is set to `site` I've opted not to perform any switching
 whatsoever, the thinking being that if the locale has been switched at
 some point for the front-end context, then we probably shouldn't adjust
 it.

 AFAICT, more testing welcomed, this works well for Core. However, there is
 a bit of an issue with CPTs. When the locale is switched, WordPress fires
 a `change_locale` action. Core hooks into this to re-register the built in
 post types and taxonomies which have their labels set statically during
 `init`. This was discussed during the initial implementation ticket.

 - https://core.trac.wordpress.org/ticket/26511#comment:61
 - #38218

 For the current use cases of `switch_to_locale()` in core, this doesn't
 seem to be an issue too often. However, AFAIK, the function is mostly used
 for mail where post type labels probably aren't being fetched. The
 inclusion of Gutenberg is going to make this issue a lot more noticeable.
 We could say that users have to "fix" their code to listen for the
 `change_locale` hook combined with supporting the Post Type Labels ticket.

 Alternately, we could try checking for the `_locale` wayyy earlier in the
 cycle. Which I believe is effectively in the
 `_get_path_to_translation_from_lang_dir()`, I'm really not sure, the
 `is_admin() ? user : site` pattern is all over the place. This would make
 the whole request occur in the user's language.

 However, it seems like a quite hacky solution.
 - We'd now be loading the current user "early" not just in the admin and
 customizer, but the front-end as well.
 - We'd probably need to do checking ourselves if this is a REST API
 request because the WP global wouldn't be setup yet.
 - We'd need to worry about the `rest_authentication_errors` filter. If
 that filter returns an error, but a user has already been set on
 `determine_current_user` What localization should we use? See the earlier
 discussion in the ticket. ( This would happen in particular if a user is
 cookie authed, but has an invalid nonce ).

 ----

 Side Note: I posted a question in Slack about changes to the test fixures,
 https://wordpress.slack.com/archives/C04KRK0KA/p1536119118000100. If
 anyone knows if just modifying the mo/po files directly is ok that'd be
 awesome!

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