[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                             |
-------------------------------------------------+-------------------------

Comment (by TimothyBlynJacobs):

 > How big of an issue are the untranslated post type labels for this?
 Happy to work on #38218 in the next few weeks. I had a PoC patch lying
 around somewhere a while ago...

 Fairly important. Gutenberg uses the labels of post types and taxonomies
 to populate important parts of the editor interface. The current path
 works fine for the built-ins because they are re-registered, but if
 someone was using Gutenberg on a custom post type, or with custom
 taxonomies, they'd see this inconsistently translated interface.

 > Also, how much trouble would it cause to set the locale way earlier than
 now to circumvent this?

 We had trouble identifying where, exactly, the translations for the
 request get set. `load_*_textdomain()` seemed like critical functions, as
 did `_get_path_to_translation_from_lang_dir()`.

 > Sounds interesting. This is already used quite a bit in WordPress, so
 I'm sure we could DRY things up a bit. Not sure if we really need yet
 another filter for this... Essentially you only need the locale filter and
 the user meta filter for the locale. I wouldn't want to change this.

 If we replaced those instances with a `determine_locale()` like function,
 it wouldn't necessarily need to be filtered. We could inline the REST API
 locale detection code.

 Assuming that part is feasible, the difficulties would be two fold.

 1. We would need to do some trickery to determine whether this is a REST
 API request before `parse_request`.
 2. On rest requests, we would be loading the current user earlier than
 expected. Previously this [early
 loading](https://core.trac.wordpress.org/ticket/29783#comment:50) would
 only happen on admin requests and the customizer. What potential fallout
 this might cause, I'm not sure.

 Something like this:

 {{{
 function determine_locale() {
         if ( ( is_multisite() && get_blog_option( null,
 'permalink_structure' ) ) || get_option( 'permalink_structure' ) ) {
                 // Not actually accurate, needs to handle index permalinks
 and paths in the home url, etc...
                 $is_rest = strpos( $_SERVER['REQUEST_URI'], '/' .
 rest_get_url_prefix() ) === 0;
         } else {
                 $is_rest = isset( $_GET['rest_route'] );
         }

         if ( is_admin() ) {
                 return get_user_locale();
         }

         if ( $is_rest && isset( $_GET['_locale'] ) && 'user' ===
 $_GET['_locale'] && is_user_logged_in() ) {
                 return get_user_locale();
         }

         return get_locale();
 }
 }}}

 I suppose this could actually happen with the existing `locale` filter.
 But we were confused whether that was the right solution or not.
 Particularly because a REST API locale seems very similar to how a
 different WP-Admin locale works, and that was implemented using the
 `is_admin() ? get_user_locale() : get_locale()` switch instead of inside
 `get_locale()` or a `locale` filter. History in #29783.

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