Make WordPress Core

Opened 9 years ago

Last modified 5 years ago

#30559 new enhancement

Plugins and themes translations aren't downloaded when language is changed

Reported by: dimadin's profile dimadin Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:


When you change language in Settings > General, translations of core for that language are downloaded, but plugins and themes translations aren't. You need to either manually upgrade translations, do any upgrade, or wait until wp_maybe_auto_update event fires, which can take couple of hours.

I tried to follow same approach as in [30554] and to hook function wp_maybe_auto_update after language is changed and cache is cleared, which should update caches and download translations, but it seems that API doesn't give translations links.

Since right now I can't investigate it in more details, I want to propose fixing this issue with something simple on WP side as in attached patch.

Attachments (1)

30559.patch (619 bytes) - added by dimadin 9 years ago.

Download all attachments as: .zip

Change History (7)

9 years ago

#1 @Chouby
9 years ago

In my experience, translations will be available at some point on a single site install. The fact that you need to click the "update translations" button is a bit inconsistent with core translations which are automatically downloaded but I guess we could live with this on a single site install.

But it seems that on a multisite install, the plugins and themes translations are *never* downloaded. Thus the network admin is obliged to upload all translations manually. The patch proposed does not fix the issue.

I believe that the problem is coming from the fact that the plugins and themes translations are downloaded through the update procedure while the core translations are explicitely downloaded with the function wp_download_language_pack().

So far I circumvent the issue with this small plugin (network activated)

// Plugin name: Plugins & themes translation updates

add_filter('themes_update_check_locales', 'pll_update_check_locales');
add_filter('plugins_update_check_locales', 'pll_update_check_locales');

function pll_update_check_locales($locales) {
	return get_available_languages();

This still needs an action from the network admin but at least it's an easier process than the manual upload. Hope it helps waiting for a better core solution.

#2 @johnbillion
9 years ago

@ocean90 Is this something that can be done for 4.4? #34029 fixed this for installing plugins and themes. It'd be great if it was fixed when switching language too.

#3 @let me see...
8 years ago

  • Keywords dev-feedback added
  • Severity changed from normal to major

As the new language management for plugins is rolled out, this seems to become more important than ever. For me, using a German subsite in an English network, Jetpack ceased to automatically translate. See this thread for details:

#4 @ocean90
8 years ago

  • Keywords needs-patch added; dev-feedback removed
  • Milestone changed from Awaiting Review to Future Release
  • Severity changed from major to normal
  • Type changed from defect (bug) to enhancement

30559.patch needs to happen async or it requires some sort of UI. Switching a language is already slow because we're clearing the caches, making it slower because of loading x plugin/theme translations without any indication feels broken.

@Chouby Changing the default value for themes|plugins_update_check_locales is something I'd support, at least for multisite installs. That should go into its own ticket.

#7 @dimadin
5 years ago

#47108 was marked as a duplicate.

#8 @afercia
5 years ago

Quoting from #47108:

Code-wise this seems to be the intended behavior, but there are some undesirable side-effects:

  • User experience is not ideal: there's nothing to inform users they have to update [Edit: click Update Translations in the Updates screen] to actually get plugins and themes translations.
  • Plugins (and themes) code relying on is_textdomain_loaded() will fail because the new language .mo file doesn't exist yet. While this is technically correct, it's a bit misleading as developers might expect it returns true once a new language has been set.

I'd tend to think software should have smart default behaviors and not require users to do manual tasks that can be avoided. Seems to me a better behavior would be automatically downloading also the plugin and theme language packs.

I'd like to propose to give this ticket some higher priority. /Cc @swissspidy @ocean90

Note: See TracTickets for help on using tickets.