#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:
- Copy the wplang-test.php into your 4.0-RCx wp-content/mu-plugins directory.
- Set a newly adding locale to the WPLANG constant in wp-config.php.
- Go to Dashboard > Updates, then click "Update Translations" button.
- Core starts downloading disired new language files automatically.
- In Settings > General > Site Language, you will see new language is selected (and locked).
- 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)
Change History (16)
#1
@
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
@
10 years ago
#4
@
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:
↓ 6
@
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
@
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.
#7
follow-up:
↓ 10
@
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.
This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.
10 years ago
#10
in reply to:
↑ 7
@
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.
#12
@
10 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 29691:
wplang-test.php