Opened 11 years ago
Last modified 2 years ago
#20974 assigned defect (bug)
Remove obsolete locale-specific files on upgrade
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | Priority: | low |
Severity: | normal | Version: | 3.4 |
Component: | I18N | Keywords: | has-patch needs-refresh |
Focuses: | Cc: |
Attachments (1)
Change History (19)
#3
@
11 years ago
Actually, ru_RU.php
could also be removed. It's only used now as a workaround for #20975.
#4
@
11 years ago
- 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.
#5
follow-up:
↓ 6
@
11 years ago
- 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.
#6
in reply to:
↑ 5
@
11 years 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). :)
#9
@
11 years ago
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 );
#10
@
11 years ago
- Keywords needs-refresh 3.6-early added
- Milestone changed from 3.5 to Future Release
#12
@
9 years ago
I have many complains (and support requests in our forum) about comment numbers so I will have to make cs_CZ.php.
See #13651
Yeah — this could also hypothetically result in conflicts for any $locale.php files.
We should be able to script this.