Make WordPress Core

Opened 8 years ago

Last modified 15 months ago

#20974 assigned defect (bug)

Remove obsolete locale-specific files on upgrade

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


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 8 years ago.
Includes some debug to allow for repeated update testing.

Download all attachments as: .zip

Change History (17)

#1 @nacin
8 years 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.

#2 @SergeyBiryukov
8 years ago

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

#3 @SergeyBiryukov
8 years ago

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

#4 @nacin
8 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: @nacin
8 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

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.

8 years ago

Includes some debug to allow for repeated update testing.

#6 in reply to: ↑ 5 @waclawjacek
8 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 still uses the locale file, only in a slightly modified form (no $wp_default_secret_key). :)

#7 @ramiy
8 years ago

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

#8 @nacin
8 years ago

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

Please review me, dd32!

#9 @dd32
8 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 @nacin
8 years ago

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

#11 @waclawjacek
8 years ago

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

Last edited 8 years ago by waclawjacek (previous) (diff)

#12 @pavelevap
6 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

This ticket was mentioned in Slack in #polyglots by sergeybiryukov. View the logs.

5 years ago

#14 @SergeyBiryukov
5 years ago

In 35710:

Add some back-compat styles for ru_RU.

This prevents the admin menu from disappearing if an old ru_RU.php file is left over after updating directly from 3.1.x or an older version to the latest release.

See #20974.

#15 @SergeyBiryukov
5 years ago

In 35711:

ru_RU: After [35710], remove fixed width for admin menu, as it does not account for media queries.

See #20974.

#16 @SergeyBiryukov
5 years ago

In 35712:

ru_RU: In back-compat styles for admin menu, inherit the width from the parent element, #adminmenuwrap, to account for media queries.

See #20974.

Note: See TracTickets for help on using tickets.