[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