[Plugin: qTranslate] Fixing "Hide untranslated content" with secondary loops

I am trying to build a multi-language site with qTranslate plugin. I make some custom page templates with secondary loops using for showing posts (like $results = new WP_Query($args);).
What I have noticed: when WordPress output posts in main query (have_posts() without any new WP_Query), qTranslate is hiding untranslated posts OK, but it can not do it with secondary loops (the posts are actually present in feed, but the titles are fixed with (Language) letters, and the content is looks like “Sorry, the content is only available in [] language”.
I am really new to WordPress, but made a little research in mechanism of this option.
What I found: the function which filter untranslated content is implemented in qtranslate_hooks.php file and looks so (line 119):

function qtrans_excludeUntranslatedPosts($where) {
	global $q_config, $wpdb;
	if($q_config['hide_untranslated'] && !is_singular()) {
		$where .= " AND $wpdb->posts.post_content LIKE '%<!--:".qtrans_getLanguage()."-->%'";
	}
	return $where;
}

There are condition !is_singular() which prevent plugin from affecting loops on any singular posts (including pages, in which I am placing my secondary loops). I checked – really, if I am using secondary loops on non-singular pages, everything is OK, so the problem is in outputting the posts inside the custom page templates. So I added another case in if statement, and now my function looks so:

function qtrans_excludeUntranslatedPosts($where) {
	global $q_config, $wpdb;
	if($q_config['hide_untranslated'] && !is_singular()) {
		$where .= " AND $wpdb->posts.post_content LIKE '%<!--:".qtrans_getLanguage()."-->%'";
	}
	elseif(is_singular() && !strpos($where, "wp_posts.post_type = 'page'")) {
		$where .= " AND $wpdb->posts.post_content LIKE '%<!--:".qtrans_getLanguage()."-->%'";
		return $where;
	}
	return $where;
}

As you can see, I check if current query is main (caused by page data itself) by !strpos($where, “wp_posts.post_type = ‘page'”), which will be inside the $where string in this case. And if it is not there, this function will work with custom queries in custom pages. Bingo!

I created this topic to share my solution with other people who has faced with this problem. And maybe somebody have more accurate solution for this problem?