WordPress.org

Make WordPress Core

Opened 22 months ago

Last modified 18 months ago

#20974 assigned defect (bug)

Remove obsolete locale-specific files on upgrade

Reported by: SergeyBiryukov Owned by: dd32
Milestone: Future Release Priority: low
Severity: normal Version: 3.4
Component: I18N Keywords: has-patch needs-refresh 3.6-early
Focuses: Cc:

Description

We used to have wp-content/languages/ru_RU.css file in ru_RU package.

Since #19603, it's no longer needed, but is still left over on upgrade. We should probably include it in $_old_files.

I suppose the same applies to zh_CN and he_IL packages ([19825]).

Attachments (1)

20974.diff (5.0 KB) - added by nacin 22 months ago.
Includes some debug to allow for repeated update testing.

Download all attachments as: .zip

Change History (12)

comment:1 nacin22 months ago

  • Milestone changed from Awaiting Review to 3.4.1

Yeah — this could also hypothetically result in conflicts for any $locale.php files.

We should be able to script this.

comment:2 SergeyBiryukov22 months ago

Just noticed that ms-$locale.po and ms-$locale.mo are also left over.

comment:3 SergeyBiryukov22 months ago

Actually, ru_RU.php could also be removed. It's only used now as a workaround for #20975.

comment:4 nacin22 months 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.

comment:5 follow-up: nacin22 months 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.

nacin22 months ago

Includes some debug to allow for repeated update testing.

comment:6 in reply to: ↑ 5 waclawjacek22 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). :)

comment:7 ramiy22 months ago

In hebrew language, he_IL.php is used to add he_IL.css to admin/login head.

comment:8 nacin18 months ago

  • Owner set to dd32
  • Status changed from new to assigned

Please review me, dd32!

comment:9 dd3218 months 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 );

comment:10 nacin18 months ago

  • Keywords needs-refresh 3.6-early added
  • Milestone changed from 3.5 to Future Release

comment:11 waclawjacek18 months ago

Please don't remove pl_PL.php - the date declension filter is necessary.

Last edited 18 months ago by waclawjacek (previous) (diff)
Note: See TracTickets for help on using tickets.