Register load_plugin_textdomain() to an action hook

[deckerweb]

As of working on a relaunch of one of my GitHub plugins I stumbled across an interesting issue: You are using the function load_plugin_textdomain() within plugin main file github-updater.php In general this is totally fine - and also recommended by Core developers. However, if the function stands just alone it could lead to strange behavior: using the Core filter 'override_load_textdomain' then will not work for your textdomain 'github-updater'.

If the function is properly registered to an action hook then all will be ok. Using 'init' with priority 1 would be best in my opinion, for example:

add_action( 'init', 'githup_updater_load_plugin_textdomain', 1 );
function githup_updater_load_plugin_textdomain() {
    load_plugin_textdomain( 'github-updater', false, basename( __DIR__ ) . '/languages' );
}

With the above wrapper also filter 'override_load_textdomain' will do fine again :) (and I would need this expected default behavior just in my above mentioned plugin... so thank you!)

[afragen]

If/when we get the Language Pack updates working I would likely remove the actual load_plugin_textdomain call from github-updater.php. I would also remove the files in /languages, leaving the POT file, in favor of the newer Language Pack updating.

Would this then still be an issue?

Also, see https://github.com/obenland/shiny-updates/issues/300 and comment.

Why does one use override_load_textdomain?

[deckerweb]

Removing language files: Yes, that's the best option to only leave a .pot file in the /languages/ folder then!

Loading function: Here I am undecided: as of my knowledge, leaving out the loading function is only possible for plugins/ themes that are hosted on WordPress.org as the .org API will do the heavy lifting. Still, Core team recommends to keep the loading function in the plugin/ theme. It will do no harm, and you can use the "shorthand" version without path & other parameter, like so: load_plugin_textdomain( 'github-updater' );

Why using the filter 'override_load_textdomain': Good question, hehe :) It's a very useful flter, especially for other languages than English, that heavily use formal and informal language variants like German. Let me give an example: there's a plugin called "Customer Area" for a locked down customer area. One possible German translation would be "Kundenbereich", if it is really used as such: an area for CUSTOMERS. For this use case I use formal business language. However, that's only one of a million use cases for such a plugin. Non-profit organisations have no "customers", they have "members" and/ or "users". So to translate it with Members -> Mitglieder or Users --> Nutzer, I have to use custom translations, in these cases the informal language variant. And these usages (overriding) are only properly possible with the use of this filter, especially since the changes in WP 4.6+. So I completely ignore existing packaged translations from the plugin or language pack and overwrite all stuff with my own wording! :) I use that mentioned plugin for some sites, each for a different use case, and therefore I need customized translations for each project (as the translations heavily influence the user here!).

Also, I use this filter to overwrite existing translations with my own, because I prefer a more consistent translation style which is also better approved for business usage. Sadly, a lot of packaged community translations are not consistent and have issues especially in business context.

[afragen]

load_plugin_textdomain now commented out in develop. https://github.com/afragen/github-updater/commit/504244856ed4c2ddab31f4d0a0cc8dc8e898a00c

Looks like I'll need to add back the more generic load command.

[afragen]

https://github.com/afragen/github-updater/commit/4fa1583d98ceb939b95792508c9c2c23e8c80ffe