[wp-trac] [WordPress Trac] #29783: User Admin Language

[WordPress Trac]

#29783: User Admin Language
-----------------------------------+-----------------------------
 Reporter:  faevilangel            |       Owner:  ocean90
     Type:  feature request        |      Status:  assigned
 Priority:  normal                 |   Milestone:  4.3
Component:  I18N                   |     Version:  4.0
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  administration
-----------------------------------+-----------------------------

Comment (by nacin):

 > '''1) Should users locale be inside `get_locale()`?'''
 > '''2) Do we need something like `get_users_locale()`?'''
 Let's first avoid considering the existing complexity of `get_locale()`,
 which includes querying a few options and caching it. The simplest API
 would be something like `get_locale( $user = false )`, where `$user` is
 `false`, `true` for current user, or `WP_User` (or user ID as `int`) for
 another user.

 In practice, this is probably both too magical and too complex. So I'd
 probably recommend `get_user_locale( $user = current )`. That way you can
 also replace all instances of `get_locale()` with `get_user_locale()` when
 appropriate, and it'll be clear why you use one over the other.

 I also don't think it'll be a compatibility concern — you don't use
 `get_locale()` often. It'd be worse if you called `load_textdomain()`
 directly in a theme or plugin and thus called `get_locale()` on your own.
 (This would support changing the default for `get_locale()` to return the
 user locale, but I don't think that'd work too well.)

 '''Currently the themes and plugins API sends the result of `get_locale()`
 too. Is this good?'''

 The .org translations API is already designed to accept an array of
 languages, as possibly dictated by the existing
 `plugins_update_check_locales` and `themes_update_check_locales` I added
 in 3.7. It was designed for someone to possibly query their entire network
 and query all of the languages that are set. (Unfortunately, `lang_id` in
 `wp_blogs` is an integer field and has never been used AFAIK.) At the same
 time, it also already handles updating all languages that are installed,
 which I think would handle this in pretty much every case? I'm not sure.
 Perhaps it needs a tweak?

 At the very least, it sounds like we should start sending an array of the
 following: the network's language (`get_site_option( 'WPLANG' )`), the
 site's language (`get_locale()`), and the user's language
 (`get_user_locale()`).

 > '''4) Should the locale be limited to the admin only? What about the
 toolbar?'''
 > Filtering a locale for the front-end shouldn't affect
 `language_attributes()` or `is_rtl()`.

 This is correct, in theory. We use both of these functions in the
 dashboard, so we need to be mindful of that. I do think the toolbar
 *should* be translated per the user's preference. This *will* complicate
 things like RTL and language attributes and such.

 ----

 This opens up a new giant question mark, which is one reason why we
 haven't really done this yet. This isn't really about the user's
 ''language''. It's about the user's ''locale''. This includes date/time
 formats (which right now are a bit of a mess, even after [31862], and have
 zero abstraction*), number formats, the user's timezone, and even calendar
 stuff like first day of the week. We should ideally approach this
 holistically, and I'd argue if not together / at the same time, then we
 should try to plot a potential course before taking the next steps.

 (* It might be time for a rewrite of `WP_Locale`.)

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