codestyling

What language do you have defined, your WordPress has to run on within the wp-config.php?
Could you explain more precisely, what isn’t working?

This is not a false alert.
Here the code snippet from actual “Contact Form 7” code version 3.4.2:

function wpcf7_get_contact_form_default_pack( $args = '' ) {
	global $l10n;

	$defaults = array( 'locale' => null, 'title' => '' );
	$args = wp_parse_args( $args, $defaults );

	$locale = $args['locale'];
	$title = $args['title'];

	if ( $locale && $locale != get_locale() ) {
		$mo_orig = $l10n['wpcf7'];
		unset( $l10n['wpcf7'] );

		if ( 'en_US' != $locale ) {
			$mofile = wpcf7_plugin_path( 'languages/wpcf7-' . $locale . '.mo' );
			if ( ! load_textdomain( 'wpcf7', $mofile ) ) {
				$l10n['wpcf7'] = $mo_orig;
				unset( $mo_orig );
			}
		}
	}

As can be seen, it uses indeed:
load_textdomain( 'wpcf7', $mofile )

The downloadable version at ru.www.ads-software.com doesn’t contain this ru_RU.php anymore.
The downloadable version at tr.www.ads-software.com contains a tr_TR.php file but it doesn’t raise any issues with my plugin in version 1.3.11

not reproducible, closed.

This bug was related to a change hook calling order by WordPress 3.6 final. It has been resolved with plugin version 1.3.11 and higher.

if this is still actual, please provide a list of installed/active plugins. if not this get closed as solved within next couple of days.

The problem is, that the plugin “Duplicator” loads the translation file during it’s load phase and not during the initialization phase of WordPress. So no other plugin has the chance to change globally languages in between cause it takes the one from wp-config.php always!

I have change the file “duplicator.php” (v0.4.6) line 226/227 and disabled the loading here:

//HOOKS
//load_plugin_textdomain('wpduplicator', FALSE, dirname(plugin_basename(__FILE__)) . '/lang/');

After disabling the loading in such a unreliable way I did insert after the disabled line:

add_action('init', 'duplicator_load_textdomain');
function duplicator_load_textdomain() {
     load_plugin_textdomain('wpduplicator', FALSE, dirname(plugin_basename(__FILE__)) . '/lang/');
}

So loading will be performed during init hook of WordPress. Now all works as expected with the “Duplicator” plugin. Please inform the author of this plugin to implement a correct hook based loading of translation files to permit other plugins choosing right languages etc.

Important: Most cases where plugins doesn’t get translated well are driven be the wrong time the translation file gets loaded. The plugin authors should load them as late as possible (this also safes the ammount of memory used, if the plugin never performs an action to produce the current requested page – front or admin)

You will need to support a own language file loaded by your plugin/theme introducing the new custom post type. Translate your i18n based phrases within you custom post type and create your mo file.
After all you will get translated custom post types too.

I would suggest to ask the polyglot list about.
As far as I know, the file creation should be automatic and should generate it at wp.org backends. But it may have been changed.

So this may lead to an alternative way getting the file(s):
– my plugin has to validate the availability of wordpress install zip
– list all possible zip based languages
– download and extract of lang files contained.

I have to think about this in terms of speed and reliability.

Will be changed with next updates. Good catch.

Seems to be a bug within www.ads-software.com packaging system.
Will try to solve it incrementing with no changes to version 1.3.12.

Seems to be a bug within www.ads-software.com packaging system.
Will try to solve it incrementing with no changes to version 1.3.12.

The compatibility issue has been fixed at version 1.3.11

The compatibility issue has been fixed at version 1.3.11

The compatibility issue has been fixed at version 1.3.11

The compatibility issue has been fixed at version 1.3.11