Prevent attempting to load en_US translation files

[jrf]

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.

[ocean90]

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

[jrf]

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

[ocean90]

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

[jrf]

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.

[ocean90]

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

[jrf]

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.

[Clorith]

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.

[dimadin]

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.

[jrf]

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.