[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):

 Replying to [comment:25 zodiac1978]:
 > Replying to [comment:24 trialotto]:
 > > [...]
 > > It would be more convenient to add an WP constant with (for instance)
 the name WPADMINLANG.
 > > [...]
 > > 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_users_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?
 >
 > The WPLANG constant is deprecated, please see:
 > https://make.wordpress.org/core/2014/09/05/language-chooser-in-4-0/


 I know, that was not the most happiest of choices, even though it is a
 very rational (and good) decision.

 Problem now arises that

 a) WordPress installations get flushed with all kinds of translations,
 when switching languages,

 b) the above is also valid for all plugins, using the get_locale()
 directive,

 c) updates for a specific language require switching to the specific
 language (and even waiting if the particular language pack update is not
 immediately detected and/or forced by the admin),

 d) and so on,

 and hence resulting in an abundance of files (in this case .po, .mo and
 .pot files), for languages that are often not used (only one language is
 selected at any given point in time).

 In short, it has been a good choice to deprecate the WPLANG constant, but
 the implications thereof have not been considered carefully.

 Nevertheless, let´s return to the issue, since the above is somewhat off-
 topic.

 Any introduction of a constant will reduce the load on the database and
 CAN increase flexibility.

 However, the current approach of

 a) identifying a website language (on the one hand), AND

 b) associating users, including admin (and therefore the local of the
 admin panel), with languages (on the other hand)

 can work properly and/or sufficiently, if one does not bother about the
 practical implications.

 One of those implications is the unnecessary use of disk space, given
 unused localisation files.

 Another implication is the necessity to update all plugins (and that can
 be a real threat).

 In short, the ability to set a separate constant for admin language should
 still be a valid alternative, besides the introduction of the possibility
 to set languages for users (i.e. end-users).

 An argument for using a separate method for setting admin language is that
 one does select one language at any given point in time, as opposed to
 users languages, that can differ amongst various users at any given point
 in time.

 The before mentioned (separate) method for setting admin language should
 still be able to use the current get_locale() directive, at least that is
 desirable (not required though).

 Kind regards....

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