WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#29456 closed defect (bug) (fixed)

Deprecating WPLANG constant is a regression

Reported by: tenpura Owned by: nacin
Milestone: 4.0 Priority: high
Severity: major Version: 4.0
Component: I18N Keywords: has-patch dev-feedback
Focuses: Cc:

Description

Current implementation for 4.0, adding new languages is not automatic. To get a new language to show up in the language switcher in the admin area, users have to manually copy language files to wp-content/languages directory.

See: #15677, http://make.wordpress.org/polyglots/2014/08/29/let-me-share-some-issues-about-4-0-language/

Seemingly this problem could be solved if the priority of the WPLANG constant is treated the same as WP 3.9.x.

I made a quick testing plugin for this demo, so anyone who's interested, please try the following steps:

  1. Copy the wplang-test.php into your 4.0-RCx wp-content/mu-plugins directory.
  2. Set a newly adding locale to the WPLANG constant in wp-config.php.
  3. Go to Dashboard > Updates, then click "Update Translations" button.
  4. Core starts downloading disired new language files automatically.
  5. In Settings > General > Site Language, you will see new language is selected (and locked).
  6. Removing WPLANG constant from wp-config.php unlocks the language switcher.

I don't see anything wrong with this flow and now my question is why the WPLANG constant is deprecated in 4.0. Is there any particular reason it should be deprecated?

The advantage of having the WPLANG constant the same as before in 4.0 is that it gives us a simple locale locking capability. The language switcher is cool and fancy new functionality, but in reality most people rarely change his/her blog locale once their blog start running. In most cases people don't want to change the locale settings of a production site accidentaly by his/her clients or even by themselves, so they could lock it with the WPLANG constant.

Attachments (2)

wplang-test.php (249 bytes) - added by tenpura 5 years ago.
wplang-test.php
29456.diff (1.2 KB) - added by nacin 5 years ago.

Download all attachments as: .zip

Change History (16)

@tenpura
5 years ago

wplang-test.php

#1 @nacin
5 years ago

  • Milestone changed from Awaiting Review to 4.0

I agree with accounting for WPLANG in this situation. Should not be hard to do.

#3 in reply to: ↑ 2 @ocean90
5 years ago

Replying to knutsp:

Related: http://make.wordpress.org/polyglots/2014/08/29/let-me-share-some-issues-about-4-0-language/#comment-256671

That's just a bad UX and should never be supported by core.

#4 @tenpura
5 years ago

One more thing to say.

Making existence of *.mo prerequisite for selectable languages like this is logically wrong and should not do.

$languages = get_available_languages();
if ( ! empty( $languages ) ) {

Locale setting is basically used for triggering locale specific codes and tasks like:

  • Outputting <html lang="xx">
  • Words or characters? counting
  • Choosing which translation files to update, etc

Loading proper translation files is of course one of these and it should be optional somehow. In fact many Japanese prefer not to load ja.mo files for their Japanese blog, but even such a case, they still need language specific functionality like character counting.

#5 follow-up: @nacin
5 years ago

I'd be open to:

  • Making the value of WPLANG selectable from the admin, even if not installed.
  • Suppressing the deprecated messages at this moment.

This should handle the concerns, I believe?

#6 in reply to: ↑ 5 @tenpura
5 years ago

Replying to nacin:

I'd be open to:

  • Making the value of WPLANG selectable from the admin, even if not installed.
  • Suppressing the deprecated messages at this moment.

This should handle the concerns, I believe?

Sounds good to me.

@nacin
5 years ago

#7 follow-up: @nacin
5 years ago

  • Keywords has-patch dev-feedback added

29456.diff works for me. Any takers?

I will note that per-user and/or dashboard-only locales can solve the problems you mention (Admin in English is a fine plugin, and I'd love to eventually get this into core, but it'll take some time), and that some users will need to adapt (generally speaking) in order to benefit the wider audience.

#8 @nacin
5 years ago

  • Priority changed from normal to high
  • Severity changed from normal to major

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


5 years ago

#10 in reply to: ↑ 7 @knutsp
5 years ago

Replying to nacin:

29456.diff works for me. Any takers?

Works very well. I was able to automatically install a new language by adding the code to wp-config.php and updating languages. Nice to have this possibility working as in 3.9.

#11 @ocean90
5 years ago

I' fine with 29456.diff. But we should probably remove it when #29395 is in.

#12 @nacin
5 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 29691:

Allow language specified by the WPLANG constant (but not installed) to be chosen.

fixes #29456.

#13 @nacin
5 years ago

Made a note on #29395. I left the deprecated notices in there as they won't be shown if WPLANG (the constant) equals WPLANG (the setting), which is the idea here.

#14 @nacin
5 years ago

See #29528 for how this will change slightly. Basically, you may no longer update WP to get the translations, but simply hit "Update Translations".

Note: See TracTickets for help on using tickets.