[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:               |     Focuses:
-------------------------+------------------------------
Changes (by TimothyBlynJacobs):

 * type:  defect (bug) => enhancement


Comment:

 I personally think that this should be a global server-level flag, like
 `_locale`. Probably just accepting `default/site` or `user` for now ( as
 opposed to accepting any installed language code ).

 The crux of the issue is that Gutenberg is an admin application where the
 user locale is meant to apply, but the REST API runs in a front-end
 context where the site locale should apply. Defaulting to the user locale
 for all requests, if they are authorized, would be changing that behavior
 which was specifically mentioned in the original user locale release post,
 https://make.wordpress.org/core/2016/11/07/user-admin-languages-and-
 locale-switching-in-4-7/, and would effect front-end uses of the REST API
 by returning user localized data when site localized data is expected.

 I believe the reason for the inconsistency when using `WP_REST_Request` is
 that Gutenberg is making these requests in the admin context, so the user
 defined locale is applied. If, however, internal requests were made in a
 “front-end” context, then the site locale should apply.

 When the server would check this flag is important. I wonder if it needs
 to apply before authentication is checked. If so, this happens in the
 global request life-cycle which doesn’t apply to internal requests. The
 utility of it happening at that point is confusing to me. If the user
 doesn’t get authenticated, then theoretically we don’t have a user object
 to fetch the locale for, but in practice, I believe the current user is
 set before the `rest_authentication_errors` and we could have an issue
 with an expired nonce, in which case we could return the error message in
 the user’s locale if desired.

 I believe this is a parameter that should be respected when doing internal
 requests as well. So it would seem, at least to me, that the server would
 also have to check the locale flag inside of `WP_REST_Server::dispatch()`
 and not change the locale if it has already been switched. Then if not
 serving the request because it is internal, restore the locale at the end
 of `::dispatch()` otherwise, we’d need to wait until right before the
 response is echoed in `WP_REST_Server::serve_request()` to restore the
 locale. Or perhaps even when the actual die happens, not sure.

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