Habemus exsarcio, there is a workaround
I encountered this same problem with bbPress in september - a too early firing to set localization...
Because it is long to obtain a fixe by the authors (delays).
The solution is based on unload_textdomain and two filters : the case jetpack is here added in bbPress solution. (xili-language plugin is compatible to a multilingual bbPress forum.
This code is here provided as example:
function xili_xl_bbp_lang_init ( ) {
if ( is_admin() )
add_filter( 'plugin_locale', 'xili_bbp_admin_side_locale', 10, 2);
}
function xili_bbp_admin_side_locale ( $locale = 'en_US', $domain = 'bbpress' ) {
if ( in_array ( $domain, array( 'bbpress' , 'jetpack' ) ) ) {
$locale = get_user_option( 'user_locale' ); // set elsewhere in xililanguage
if ( empty( $locale ) ) {
$locale = ( defined( 'WPLANG' ) ) ? WPLANG : 'en_US';
if ( is_multisite() ) {
if ( defined( 'WP_INSTALLING' ) || ( false === $ms_locale = get_option( 'WPLANG' ) ) )
$ms_locale = get_site_option( 'WPLANG' );
if ( $ms_locale !== false )
$locale = $ms_locale;
}
}
// example for jetpack
unload_textdomain( 'jetpack' );
load_textdomain( 'jetpack', WP_PLUGIN_DIR.'/jetpack/languages/jetpack-'.$locale.'.mo' );
}
return $locale;
}
add_action( 'plugins_loaded', 'xili_xl_bbp_lang_init', 9 ); // 9 = to be registered before bbPress instantiate
With these few lines, webmaster in the admin side is able to choose 'live' his language.
M.