WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 8 months ago

#39639 new enhancement

Increase cache time on wp_get_available_translations()

Reported by: leewillis77 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.8
Component: I18N Keywords:
Focuses: Cc:

Description

Currently there's no nice way of retrieving a full list of supported languages / locale codes from WordPress. The closest seems to be:

require_once( ABSPATH . 'wp-admin/includes/translation-install.php' );
$languages = wp_get_available_translations();

This calls the WordPress.org API to retrieve the list, making this approach not wholly suitable outside of its original intended use during WordPress install. The results are currently cached for 3 hours so it's not that the API will be called every time this function is called, however it seems that the 3 hours could be extended reasonably safely without causing any detriment.

Patch attached that extends the cache time to 24hrs.

Attachments (1)

39639-increase-cache-time-on-wp-get-available-translations.diff (506 bytes) - added by leewillis77 8 months ago.
Patch that extends cache time to one day.

Download all attachments as: .zip

Change History (4)

@leewillis77
8 months ago

Patch that extends cache time to one day.

#1 @johnjamesjacoby
8 months ago

A few observations:

  • 3 * HOUR_IN_SECONDS is also used for getting popular tags from WordPress.org plugins, and for the feature list in themes
  • Feeds, cron, nonces, and plugins, themes, and core updates, all use 12 * HOUR_IN_SECONDS
  • Auth cookies use 14 * DAY_IN_SECONDS

I think what's really missing here is a _maybe_update_translations function in wp-includes/update.php. That function/API would ideally be tied to the same 12 hour interval that the other file-system checks use.

I don't think 3 hours is too long or too short, but it would be nice to be able to manipulate these intervals more easily, and for them to be exposed and used in a way that centralizes them (because right now they're scattered around everywhere.)

My recommendation would be to:

  • Introduce a new wp_get_update_interval() function with a parameter for the thing being updated, and a filter at the end to allow it to be manipulated.
  • Use this new function everywhere things requiring updating occur
  • Keep this function public to allow plugins to add their own update interval keys
  • Update the Heartbeat API to use this, too

This way, people wanting fewer updates to wporg can more easily target them, and plugins wanting to play nicely can more easily do so with a higher rate of success and without hooking into lower-level options/transients APIs to do so.

#2 follow-up: @ocean90
8 months ago

  • Keywords reporter-feedback added

making this approach not wholly suitable outside of its original intended use during WordPress install.

That's correct. What's your actual use case? We use the function only on install and on the settings page. Having a short cache time makes it possible to switch to a new language without having to wait too long.

#3 in reply to: ↑ 2 @leewillis77
8 months ago

  • Keywords reporter-feedback removed

Replying to ocean90:

What's your actual use case?

I have a plugin that needs to let people enter information, and as part of that choose which "language" it applies to. So - I want to have a dropdown of all possible languages. That dropdown is shown on the admin pages of the plugin, so if someone is working with the plugin there's the potential for it to cause the API to be hit more frequently that you might expect.

We use the function only on install and on the settings page. Having a short cache time makes it possible to switch to a new language without having to wait too long.

Will someone really be likely to want to switch to a new language within 3 hours of it being released? Would 24 hours not be just a reasonable? Especially since the data will only be in the cache if they've visited the admin page, or installed within the last 24hrs anyway...

There's potentially another couple of issues that could be raised about this, namely about moving it out of its current home, and into somewhere that's included already so anyway wanting to use it doesn't have to include translation-install.php, and also making sure it always returns all languages as currently en_US isn't included. [I get that en_US is the default, and not a "translation"...]. Happy to raise separate tickets if you think it makes sense to do so?

Does that make sense?

Note: See TracTickets for help on using tickets.