[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:  Future Release
Component:  I18N                   |     Version:  4.0
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  administration
-----------------------------------+-----------------------------

Comment (by trialotto):

 I have registered, just to comment on this topic.

 In essence, the topic "user languages", for multiple admins (users) with
 different languages, is addressed.

 It surprises me how little attention is being paid to issues, related to a
 necessity to have an admin panel with a specific language, while having a
 different site language.

 Naturally, a "quick fix" (in the form of a get_user_language() function)
 or even a "work-around" (in the form of symlinking .mo files) can be
 identified and implemented.

 However, in my humble opinion, that is restrictive and not the proper way
 of doing things.

 For instance, most of plugins are using the get_locale() directive and it
 can be expected that, at least in most cases, the implementation of this
 directive will not and/or cannot change, given the fact that the "common
 plugin" will and/or has to use the language, set in wp-config.php.

 A (very) simple and alternative solution can be found in implementing a
 process, similar to that of the site language, that can be freely chosen.

 In summary, the site language can be set in the general settings.

 It would be more convenient to add an WP constant with (for instance) the
 name WPADMINLANG.

 This would require a couple of lines in the code, defining WP constants.

 In addition, the get_locale() directive can be augmented with some (minor)
 lines of code, reading both the WPLANG and the WPADMINLANG and passing
 them on to the various php files using get_locale().

 This would be a simple, fast and more flexible (!) solution, not requiring
 any heavy adjustments of code and/or change of code of all (!) plugins
 and/or creation of a new get_user_locale() directive.

 Maybe I am missing the point and/or some relevant information, but why
 does one not opt for the above or a similar solution?

 Kind regards....

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