Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#29456 closed defect (bug) (fixed)

Deprecating WPLANG constant is a regression

Reported by: tenpura's profile tenpura Owned by: nacin's profile 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 10 years ago.
wplang-test.php
29456.diff (1.2 KB) - added by nacin 10 years ago.

Download all attachments as: .zip

Change History (16)

@tenpura
10 years ago

wplang-test.php

#1 @nacin
10 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
10 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
10 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
10 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
10 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
10 years ago

#7 follow-up: @nacin
10 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
10 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.


10 years ago

#10 in reply to: ↑ 7 @knutsp
10 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
10 years ago

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

#12 @nacin
10 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
10 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
10 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.