Opened 11 months ago
Last modified 7 months ago
#20974 assigned defect (bug)
Remove obsolete locale-specific files on upgrade
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | low | Milestone: | Future Release |
| Component: | I18N | Version: | 3.4 |
| Severity: | normal | Keywords: | has-patch needs-refresh 3.6-early |
| Cc: |
Attachments (1)
Change History (12)
comment:2
SergeyBiryukov — 11 months ago
Just noticed that ms-$locale.po and ms-$locale.mo are also left over.
comment:3
SergeyBiryukov — 11 months ago
Actually, ru_RU.php could also be removed. It's only used now as a workaround for #20975.
- Priority changed from normal to low
This isn't high priority, but we should probably identify any *.php locale files that we removed from 3.3 to 3.4, and put those in the upgrade routine. Otherwise I imagine they risk causing problems.
- Keywords has-patch added
- Milestone changed from 3.4.1 to 3.5
Though I posted to the P2, I was able to sufficiently script this.
These locales had a locale.php file in their latest 3.3.x build but not in their 3.4 final build: sv_SE
pl_PL
ar
id_ID
nb_NO
fi
en_CA
nn_NO
eo
ckb
pt_BR.
zh_CN, he_IL, and ru_RU still do have locale.php files.
All of these locales are either $wp_default_secret_key or $text_direction, so they are harmless. pl_PL also adds a date declension filter, but again, harmless as-is and won't break core. So, moving to 3.5.
This is not as easy as just adding files to $_old_files, because we have to detect a custom language directory. Here's a patch that is one way to implment this.
comment:6
in reply to:
↑ 5
waclawjacek — 11 months ago
Replying to nacin:
These locales had a locale.php file in their latest 3.3.x build but not in their 3.4 final build: sv_SE
pl_PL
pl_PL still uses the locale file, only in a slightly modified form (no $wp_default_secret_key). :)
In hebrew language, he_IL.php is used to add he_IL.css to admin/login head.
- Owner set to dd32
- Status changed from new to assigned
Please review me, dd32!
Looks sane, untested, but I assume nacin did that..
Only question is, do we need to be recursively deleting the file?
$wp_filesystem->delete( $old_file, true );
comment:10
nacin — 7 months ago
- Keywords needs-refresh 3.6-early added
- Milestone changed from 3.5 to Future Release
comment:11
waclawjacek — 7 months ago
Please don't remove pl_PL.php - the date declension filter is necessary.

Yeah — this could also hypothetically result in conflicts for any $locale.php files.
We should be able to script this.