Spurious translation files added during update

I just updated philippinstories.com to 1.0.0-rc1 and encountered an interesting phenomenon.

The site runs in en-GB (settings general page) and is in Manila timezone.

The update said it would download and install en-US. I figured no harm since it should add en-GB translation files if needed.

After updating, it said sit tight while we update your translations and then it proceeded to download and install es-ES translation files for core, some plugins and some “twenty series” themes.

Where the heck did it get the idea I wanted to use Spanish?

1 Like

It’s doing that on a lot of the sites I have updated too. I think it must just be a new or different language file that needs updating as a matter of course.

I can’t think of a valid reason why a core update in language A (en-US) that is installed on a site running language B (en-GB) would need to install translation files for language C (es-ES).

Those files are simply not required (and the site has never been set to es-ES), so in my book this means it’s a bug which needs to be squashed before 1.0.0 is released.

If anyone can show that this isn’t a bug, please go ahead!


I would like to know the answer to this too. @Mte90 any ideas?

Also reported in another thread:

@ozfiddler:what was it that made you think these two plugins in particular really wanted a Spanish update?

It reported it at some stage in the process. There have been others that have done that since. I just assumed there was a particular language file that needed to be updated.

1 Like

@zigpress I am not sure this should hold up the 1.0.0 release. We’ll find what there is to fix here and fix it as soon as we can, but since this isn’t going to break any sites, that can just as easily be in 1.0.1 (or on our servers, if it turns out that’s where the fix needs to happen).

Steps to reproduce this issue (e.g. install 1.0.0-beta2 and plugin X, do the upgrade to rc1) would be helpful in order to get to the bottom of it more quickly.

1 Like

Here are some screenshots… seems to have done it on most of my sites now that I go back and check:

when clicked:


I can’t provide steps to reproduce since the site in question used to be a WP site before migration, and will have experienced various plugin updates, additions, removals etc before migration.

What I can say is that

  • it was a beta2 CP site before updating
  • it was set to en-GB (and always had been since creation)
  • I used the auto-update prompt link and it added the translations straight after completing the core update, without asking for confirmation or input
  • the theme is a home-made child theme of Twenty Sixteen that hardly changes anything
  • the following plugins are installed: All In One SEO, Google Analyticator, Hupso Share Buttons, MainWP Child, Open Currency Convertor, SG Optimiser, Shield, Simple Links, UpdraftPlus.

I think that is only logical if the plugin or theme that has triggered the update has it’s language files hosted at https://translate.wordpress.org/

To me this indicates that the ClassicPress update mechanism is working as it should as those plugins/themes may have had their language files updated since the fork and therefore not a bug with CP.

@anon63659058 but why load language files from a completely unrelated and unwanted language? I don’t buy the “not a problem” answer.

1 Like

@zigpress are the language files being “loaded” or simply have been updated?

If they are being “loaded” on site then we have an issue but if they have simply been updated then that is not a bug. If those language files were self hosted then they would be sitting in the plugin/theme and that in itself is not an issue per se!

Can you confirm if they are being loaded on the site and thus have an unintended effect on the site?

I don’t think they’re being loaded when the site loads a page.

What is happening is that they’re being downloaded from somewhere and added to the languages folder inside wp-content (they weren’t there before - I checked), so that folder is being cluttered with language files that shouldn’t be there.

That is normal behaviour in WordPress for translate wp org served languages, see index.php file in the languages folder of BBPress - this applies to all plugins/themes that use the WordPress translation service.

Confirming that I am getting the same issue with spurious Spanish translation files being added on all 5 sites I’ve upgraded to 1.0.0.-rc1

Very strange as behaviour because WP download the locales only based on the settings and not plugins.
Basically if your website is configured for en_gb as example only this language is downloaded, other languages are downloaded if an user is using a different locale configured in his profile.
I don’t think that is the case for all this website and also only for spanish and not other locales.
I tested now with a new website installed with rc1 and this problem doesn’t happen.

I will do now tests on migrate a beta2 to rc1 and see what happen.


The problem happen on migration from beta to rc1.
Looking on the database after the migration the transient _site_transient_update_themes and _site_transient_update_plugins include as locale es_ES because the file is downloaded and available so the other transients will check for this locale on the servers and will download that files.
In CP code the only reference to this locales are in the unit tests https://github.com/ClassicPress/ClassicPress/search?q=es_ES&unscoped_q=es_ES so I will investigate further.

On the API endpoint es_ES is the 9 item https://api-v1.classicpress.net/translations/core/1.0.0/translations.json so seems something more random.
With a test upgrading from beta-1 to rc1 confirmed again the problem so is something on the rc-1 in the upgrade procedure.

The only change to upgrade procedure since beta2 is https://github.com/ClassicPress/ClassicPress/commit/a85a5a76fcac9fcd7d33762ffd06371f34ad841a about the semver but doesn’t involve the locales.
Also if the migration is done manually with an overwrite of the files the problem doesn’t happen.
The issue now is how debug the upgrade procedure to understand what is happening.

Set also CORE_UPGRADE_SKIP_NEW_BUNDLED has true doesn’t block that issue.

Found where is the issue!
The problem is in the package of the rc-1 build that include the locales https://github.com/ClassicPress/ClassicPress-release/tree/master/wp-content/languages
This explain why they are not downloaded and the bug exists only on rc-1 and with this specific locale.
Maybe the build bot need to cleanup this folder to be sure :slight_smile:

I think that we can update the packages of rc-1 and remove this files @james


:tada: Good find, thank you!

Indeed, these two files should not be in a release: https://github.com/ClassicPress/ClassicPress-release/tree/1.0.0-rc1/wp-content/languages

I made a mistake when preparing 1.0.0-rc1, I had Spanish installed on my local test site and it got included with the release.

We won’t update an existing release, the release is already out with existing commit hashes, file hashes, etc.

However I will make sure this gets removed/fixed in 1.0.0 final.


Great diagnosis guys - it’s good to know we weren’t imagining things and there’s an easy fix.