Make WordPress Core

Opened 12 years ago

Last modified 5 months ago

#20974 assigned defect (bug)

Remove obsolete locale-specific files on upgrade

Reported by: sergeybiryukov's profile SergeyBiryukov Owned by: dd32's profile dd32
Milestone: Future Release Priority: low
Severity: normal Version: 3.4
Component: I18N Keywords: has-patch needs-refresh close
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 12 years ago.
Includes some debug to allow for repeated update testing.

Download all attachments as: .zip

Change History (20)

#1 @nacin
12 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
12 years ago

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

#3 @SergeyBiryukov
12 years ago

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

#4 @nacin
12 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
12 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.

12 years ago

Includes some debug to allow for repeated update testing.

#6 in reply to: ↑ 5 @waclawjacek
12 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
12 years ago

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

#8 @nacin
12 years ago

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

Please review me, dd32!

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

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

#11 @waclawjacek
12 years ago

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

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

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

9 years ago

#14 @SergeyBiryukov
9 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
9 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
9 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.

#17 @desrosj
4 years ago

  • Milestone set to Future Release

@SergeyBiryukov it looks like you took care of the Russian locale, but there are still others that may be affected by this. Is this worth pursuing? Or has the ship sailed and we should close this out?

#18 @hellofromTonya
4 years ago

  • Keywords 3.6-early removed

Is there more work to do in this ticket? Or is it ready to be closed out?

#19 @swissspidy
5 months ago

  • Keywords close added

Not a fan of automatically deleting <locale>.php because wp-settings.php automatically loads that file if it exists, and there can be legacy systems where these files were manually added. That's why the new translation file extension in 6.5 is <locale>.l10n.php and not just <locale>.php.
SO if anyone has e.g. a custom pt_BR.php file, this change would break their site.

Suggesting wontfix.

Note: See TracTickets for help on using tickets.