codestyling

I’ve tested this plugin locally and the author defined the textdomain in a way not qualified parseable. Nevertheless I wrote additional code for upcomming version 1.99.10 having at least a work arround for this problem. But this also results in a “maybe” classification of this plugin even if it works afterwards.
Other plugins doing similar unparseable things may not be working, thats why it got this classification too.
If the author would have been using a constant definition for the textdomain, it would not be a problem. But having this at a variable makes it impossible to find while plugin is not active.
Please update to the upcomming version if it is available in a few hours.

Could be, that your theme doesn’t support translation. Without a link for free download I can’t support or analyse it.

This has been solved with version 1.99.8 of this plugin.
Reason of error: The plugins did generate a *.mo file on an empty catalog.
Empty catalog means, that there are no translations at all. But the fix doesn’t solve the situation while having “damaged” *.mo files. Please delete the affected *.mo files first.

Fix: You will get now an error message while trying to create empty *.mo files. So please translate at least one entry to be able to produce a valid mo-file.

Could you please describe the problem more specific?
What are you doing while this happens? Without any steps to reproduce this I’m unable to find a solution for.

@pavelevap: The answer is yes and no 🙂
Indeed I could prepend something, but this would be no general solution. Each theme may do this by its own way so this is more like guessing arround or I had to create (and to support) an extra ordinary list of theme to filename mapping, where I have to register all this exotic themes doing it a way beside the normally intended way.
That’s why my decision was to emmit this warnings with possible work arrounds, sorry if this is not suitable enough for immediate translation checking.
But as long as there is not common defined way to handle all the problems around themes/childthemses, I see no other way dealing with this.
… still working at a comprehensive WP core patch solution.

My Problem is, that it scans source files on disk an try to find it out of it. This is a huge text analysis because themes/plugins need not to be activated to deal with this. So I need a ways to be sure about standards of utilization of files to be generated.

Even if this could be hooked the standards is:

function load_theme_textdomain( $domain, $path = false ) {
	$locale = apply_filters( 'theme_locale', get_locale(), $domain );

	$path = ( empty( $path ) ) ? get_template_directory() : $path;

	$mofile = "$path/$locale.mo";
	return load_textdomain($domain, $mofile);
}

This implies, that any language file for Themes (in opposite to Plugins) only consists of “$locale.mo”, in german case “de_DE.mo”
This is what I call standard.

I know your problem by updating parent theme and loosing the user modified translations but your localization would also work as done, if you would use the standards like “de_DE.mo” instead of “hybrid-de_DE.mo” (which is plugin naming).

Nevertheless I’m also working on a proper way how WordPress can fulfill your need out of the box. If it’s working stable, I will put the patch.diff to the trac.