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

WordPress Trac noreply at wordpress.org
Wed Sep 21 13:24:32 UTC 2016


#29783: User Admin Language
-------------------------------------------------+-------------------------
 Reporter:  faevilangel                          |       Owner:  ocean90
     Type:  feature request                      |      Status:  assigned
 Priority:  normal                               |   Milestone:  4.7
Component:  I18N                                 |     Version:  4.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  refresh                                        |  administration
-------------------------------------------------+-------------------------

Comment (by ocean90):

 Replying to [comment:41 swissspidy]:
 > * Should `{$locale}.php` be loaded for both locales?

 To answer this question we should take a look at existing `{$locale}.php`
 files:

 * Myanmar (Burmese):
    * File: https://i18n.trac.wordpress.org/browser/my_MM/trunk/dist/wp-
 content/languages/my_MM.php
    * The last release was 4.1.
 * Persian:
   * File: https://i18n.trac.wordpress.org/browser/fa_IR/tags/4.6.1/dist
 /wp-content/languages/fa_IR.php
   * Setting the global is no longer required.
 * Hungarian:
   * File: https://i18n.trac.wordpress.org/browser/hu_HU/branches/4.2/dist
 /wp-content/languages/hu_HU.php
   * The file is from 4.2, since 4.3+ the file is no longer bundled but it
 may still exist. (Related: #20974)
 * Serbian:
    * File: https://i18n.trac.wordpress.org/browser/sr_RS/trunk/dist/wp-
 content/languages/sr_RS.php
    * `$wp_default_secret_key` is no longer used, the rest is for
 converting Cyrillic letters to Latin.
 * Chinese (China):
    * File: https://i18n.trac.wordpress.org/browser/zh_CN/trunk/dist/wp-
 content/languages/zh_CN.php
    * The last release was 4.5.3. Adds oEmbed providers and a setting for
 an "ICP license number"
 * Chinese (Taiwan):
    * File: https://i18n.trac.wordpress.org/browser/zh_TW/tags/4.3/dist/wp-
 content/languages/zh_TW.php
    * The file is from 4.3, since 4.4+ the file is no longer bundled but it
 may still exist.
 * Polish:
    * File: https://i18n.trac.wordpress.org/browser/pl_PL/branches/4.3/dist
 /wp-content/languages/pl_PL.php
    * The file is from 4.3, since 4.4+ the file is no longer bundled but it
 may still exist.

 Our long-term goal is to get rid of all the locale files, either by moving
 the code into core or a plugin. I think we shouldn't change the existing
 loading behaviour and load only a locale file for the site language.

 [[BR]]


 > * Imagine the following scenario: site locale is en_US, user locale is
 not set yet.
 >  1. Change user locale to es_ES. Expected: backend is in es_ES. Actual:
 backend is in es_ES, frontend is in es_ES ''and'' us_US. Pretty weird, see
 https://cloudup.com/c7ZU9Ov2ECl for a screenshot.
 >  2. Go to Settings -> General. Expected: site locale is shown as en_US.
 Actual: es_ES is selected.
 >  3. Change site locale to nl_NL. Expected: backend is still es_ES.
 Actual: The success admin notice is in nl_NL, the rest is in es_ES.
 Frontend is still mixed nl_NL and es_ES.

 1. That's because in your latest patch `wp-settings.php` still contains
 `$locale = get_user_locale()`. `$locale` should always hold the site
 language so it needs to be `$locale = get_locale()`. Based on my answer
 for the locale.php I think we can leave `wp-settings.php` as it is.
 2. See 1.
 3. That's caused by [https://core.trac.wordpress.org/browser/trunk/src/wp-
 admin/options.php?rev=38032&marks=219-225#L218 these lines] to fix #29281.

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


More information about the wp-trac mailing list