WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#31318 closed defect (bug) (wontfix)

options-general.php have "Site Language" set to (current view language) but should be (site language)

Reported by: Profforg Owned by: ocean90
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: I18N Keywords: has-patch
Focuses: administration Cc:

Description

Hi.

While you edit General Options /wp-admin/options-general.php option "Site Language" always set to (current view language) but should be (site language). Let's say that you have installed any WordPress plugin to have admin panel and website to be in your language (Example: WP Native Dashboard, WPML Multilingual CMS), you are comfortably use admin interface in your language, but when you come to general options and edit something - you ALWAYS need to set language to correct site language. It's a pain to have this.

I think "Site Language" should be Site Language, not current language in which you view admin panel.

I think it's a bug. If not, then consider this as enchancement request.

Versions affected: After removing WPLANG constant from wp-config.php. If i remember right, it's 4.0+.

Sincerely,

Alex.

Attachments (3)

31318.patch (899 bytes) - added by jubstuff 4 years ago.
31318.2.patch (576 bytes) - added by brokenflipside 4 years ago.
This is a refresh
31318-3.patch (576 bytes) - added by brokenflipside 4 years ago.
Uploaded the wrong file, this is correct

Download all attachments as: .zip

Change History (14)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to I18N
  • Focuses accessibility removed

#2 @khromov
5 years ago

This is a bug for sure. There is a patch over in #29362, hoping it gets traction.

#3 @johnbillion
4 years ago

  • Focuses ui removed
  • Keywords needs-patch good-first-bug added
  • Milestone changed from Awaiting Review to Future Release

@jubstuff
4 years ago

#4 @jubstuff
4 years ago

  • Keywords has-patch added; needs-patch removed

This is a patch originally from @khromov in ticket #29362.

It correctly set the option as the site language in the language dropdown in general settings if, for example, the dashboard and site language differ.

I used the "WP Native Dashboard" plugin to test it out.

G

#5 @swissspidy
4 years ago

  • Keywords needs-refresh needs-testing added

I'd say this is a one liner, just replacing $locale = get_locale(); with $locale = get_option( 'WPLANG' );.

@brokenflipside
4 years ago

This is a refresh

#6 @brokenflipside
4 years ago

  • Keywords needs-refresh removed

I have made the recommended changes and attached the patch. I changed the language refreshed and it was displaying the correct choice as active.

@brokenflipside
4 years ago

Uploaded the wrong file, this is correct

#7 @swissspidy
4 years ago

  • Keywords needs-testing removed
  • Milestone changed from Future Release to 4.5

I've tested this using Polylang on both trunk and 4.3.

Current behaviour:

  • Set site language to German
  • Change user language to English
  • Admin is in English and the site language is displayed as being English

With the patch applied:

  • Set site language to German
  • Change user language to English
  • Admin is in English and the site language is displayed correctly as being German

According to @ocean90 get_locale was probably used for compatibility reasons for sites that don't have the WPLANG option set, but the upgrade_400() function sets it for any site anyway.

Therefore the patch should be good to go.

#8 @swissspidy
4 years ago

  • Owner set to ocean90
  • Status changed from new to assigned

Apparently there was a good reason for using get_locale(), see https://core.trac.wordpress.org/ticket/29362#comment:8.

@ocean90 You decide ;)

#9 @ocean90
4 years ago

  • Keywords close added; good-first-bug removed

get_locale() is the site language. It gets used for update checks for example. It also includes the back compat stuff like support for the old WPLANG constant or the $wp_local_package global.

#29783 will introduce a new API to separate user and site language and should solve this issue too.

#10 @swissspidy
4 years ago

  • Keywords close removed
  • Milestone 4.5 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Closing in favour of #29783.

@jubstuff @brokenflipside You're very welcome to work on patches for that ticket :-)

This ticket was mentioned in Slack in #core-i18n by swissspidy. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.