Plugins: when to fire load_plugin_textdomain() : example with jetpack.

This post

http://wordpress.org/support/topic/jetpack-not-correctly-translated-by-multilingual-plugins?replies=6

describes some troubles with jetpack in multilingual context (don’t confuse with localisation) because the function was called very soon and it is impossible to hook plugin (class) initialisation and function containing load_plugin_textdomain

To avoid unload textdomain, the best stage is when the filters (by plugins) are placed at good places in queues (plugins_loaded) and when the capabilities of user is known (plugin_locale).

in jetpack, the plugin is started here (end of file jetpack.php):

register_activation_hook( __FILE__, array( 'Jetpack', 'plugin_activation' ) );
register_deactivation_hook( __FILE__, array( 'Jetpack', 'plugin_deactivation' ) );

add_action( 'init', array( 'Jetpack', 'init' ) );
add_action( 'plugins_loaded', array( 'Jetpack', 'load_modules' ), 100 );
add_filter( 'jetpack_static_url', array( 'Jetpack', 'staticize_subdomain' ) );

Jetpack_Sync::sync_options( __FILE__, 'widget_twitter' );

At the end, 2 actions and one filter are enqueued to instanciate class (init) and more…

The init function load also mo file of plugin based on WPLANG of wp-config.php

public static function init() {
		static $instance = false;

		if ( !$instance ) {
			load_plugin_textdomain( 'jetpack', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );
			$instance = new Jetpack;

			$instance->plugin_upgrade();
		}

		return $instance;
	}

After add_action( ‘plugins_loaded’,… at a level 100 – very late after current level 10 by default

Curiously this line at end :
Jetpack_Sync::sync_options …

After checking sources, this sync_options also call init the class via function enqueued in add_action (‘init’… – redundant ???

Where are the do_action (init and plugins_loaded) in wp_settings ?

After plugin files including loop. (plugins_loaded) and after user capabilities are known for init
So firing load_plugin_textdomain when main core jetpack class is instantiated is not optimum and not good for multilingual context.
Because here Jetpack_Sync::sync_options call is fired during the plugin files including loop !!

What is suggested ?

put the load_plugin_textdomain in his own function in jetpack class

public static function init() {
		static $instance = false;

		if ( !$instance ) {
			//load_plugin_textdomain( 'jetpack', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );
			$instance = new Jetpack;

			$instance->plugin_upgrade();
		}

		return $instance;
	}

	public static function plugin_textdomain() {
		load_plugin_textdomain( 'jetpack', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );
	}

enqueue it in init action at level 11

and now all is poetry and other plugins can personalize languages behaviour in admin side according user preset wish about his language. In admin side, the user can also live change the displayed language without a specific hook (hack) like in xili-language plugin.

add_action( 'init', array( 'Jetpack', 'init' ) );
add_action( 'init', array( 'Jetpack', 'plugin_textdomain' ), 11 );
add_action( 'plugins_loaded', array( 'Jetpack', 'load_modules' ), 100 );
add_filter( 'jetpack_static_url', array( 'Jetpack', 'staticize_subdomain' ) );

Jetpack_Sync::sync_options( __FILE__, 'widget_twitter' );

subsidiary question : why Jetpack_Sync::sync_options is not enqueued by example in plugins_loaded action ?

Michel

http://wordpress.org/extend/plugins/jetpack/