Remove obsolete locale-specific files on upgrade

[SergeyBiryukov]

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]).

[nacin]

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

We should be able to script this.

[SergeyBiryukov]

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

[SergeyBiryukov]

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

[nacin]

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.

[nacin]

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.

[nacin]

Includes some debug to allow for repeated update testing.

[waclawjacek]

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). :)

[ramiy]

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

[nacin]

Please review me, dd32!

[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 );

[waclawjacek]

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

[pavelevap]

I have many complains (and support requests in our forum) about comment numbers so I will have to make cs_CZ.php.

See #13651

[SergeyBiryukov]

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.

[SergeyBiryukov]

In 35711:

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

See #20974.

[SergeyBiryukov]

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.

[desrosj]

@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?

[hellofromTonya]

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

[swissspidy]

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.