Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#36491 closed defect (bug) (wontfix)

Prevent attempting to load en_US translation files

Reported by: jrf Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: has-patch
Focuses: performance Cc:


As en_US is the default language, there is no need to attempt to load translation files for it.

However, WP still does.

This can - on an average WP install - easily result in some 40+ file system calls to check for the existence of en_US translation files. These call are unnecessary and slow down the page load.

The included patch would solve this by bowing out early if the locale is en_US.

Attachments (2)

36491-leaner-loading-en_US.patch (3.1 KB) - added by jrf 5 years ago.
test-plugin.zip (2.8 KB) - added by ocean90 5 years ago.

Download all attachments as: .zip

Change History (13)

#1 @jrf
5 years ago

  • Keywords has-patch added

#2 @ocean90
5 years ago

  • Keywords close added

This would break any theme/plugin which isn't per default in en_US.

#3 @jrf
5 years ago

@ocean90 Can you elaborate on that ? I've never come across that situation and wouldn't even know how to simulate it to do some testing.

#4 @ocean90
5 years ago

Example: The default language of a plugin is de_DE, to provide support for English the plugin ships a language file for en_US.

#5 @jrf
5 years ago

Eh.. but how do you set a different default language for a plugin ? And how does WP recognize that ?
Got a link to a plugin or theme which does that ? I'd like to run some tests with it for the Debug Bar Localization plugin.

5 years ago

#6 @ocean90
5 years ago

@jrf See test-plugin.zip. You don't have to define the default language explicit, it can be any language.

#7 @jrf
5 years ago

Ok, thanks. I'll have a play with it. The performance difference with the short-circuit is very noticeable, so I'll see if I can come up something anyway.

Any idea if this (plugins/themes defaulting to non-en_US) is a regular thing ? I'd never come across it before.

#8 @Clorith
5 years ago

I'd say it happens fairly often in many locales where English is a 2nd or 3rd language (or not at all).

I've seen my fair share of Chinese ones for example, and I've even done this my self in Norwegian when a client only wants it in their language, then changes their mind a year or so later and I just append en_US translation files.

#9 @dimadin
5 years ago

You have override_load_textdomain filter that will prevent loading:

add_filter( 'override_load_textdomain', '__return_true' );

Or change this line if you want to check if locale is en_US.

There is no reason to have special case for en_US since filters are for that.

Another thing is that you can have en_US translation files to override default strings and this change would break this too.

#10 @jrf
5 years ago

All very good points. Thank you all for your feedback.
In the light of this, please close this issue.

If I can think of another way to lower the performance hit this causes at some point in the future, I'll ask for a re-open.

On the matter of non-en_US default languages for themes/plugins: anyone know of a way to detect this so I could make this more visible in DBL ?
Low prio, but could be useful for someone when debugging a site where - for instance - a widget shows up in Chinese because of this and the site-admin is not aware of the fact that plugins/themes can have non-standard default locales.

#11 @DrewAPicture
5 years ago

  • Focuses performance added
  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.