Unknown column 'e.language' when filtering taxonomy source by source language

I'm getting the same error on a clean install. No pending updates or anything. Did you find any solution to this? Is this a drupal core bug in pager.inc and should maybe be reported there?

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'e.language' in 'where clause': SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM {taxonomy_term_data} e WHERE (e.language = :db_condition_placeholder_0) ) subquery; Array ( [:db_condition_placeholder_0] => en ) in PagerDefault->execute() (line 74 of /path/to/drupal/includes/pager.inc).

I'm trying to use entity translation for taxonomy terms, and all my terms don't have a language assigned (yet), maybe that is the problem. From looking at the URL that caused the error, I can see that I tried to filter for language=en, as there is no language neutral option in the exposed filter:

/admin/tmgmt/sources/entity_taxonomy_term?name=&language=en&vocabulary_machine_name=&target_language=&target_status=untranslated_or_outdated

maybe this helps to figure out what's happening? Just trying to give some context here...

Have you enabled the i18n_taxonomy module? That should add the language column to the table.

Hi Say_Ten, thanks for getting back on this.

No, I don't have i18n_taxonomy enabled, as I understood, this is not necessary and potentially fatal if used in combination with entity_translation. It's quite complicated to find out what modules need to be enabled in order to have a working multilingual site nowadays with some i18n modules needed, some working together well and some messing everything up badly with field_translation.

I think the related issues shed some light on the background on this, but this is way over my head to try to mess with right now. As I understand, if I have entity translation to start with and then install i18n_taxonomy, the language of the terms is being reset to language 'und' whenever I save a taxonomy. There is work under way to solve this in the entity_translation and i18n issue queues, therefore I'm leaving this problem for the time being as I have more urgent things at hand right now.

But back to tmgmt... does this only work with i18n_taxonomy or is it supposed to work with entity_translation at all? Is it a matter of the right configuration or could we call this a bug? Is there an easy way to not rely only on e.language column, that apparently isn't there if one doesn't install i18n_taxonomy?

Unfortunately I don't have the time right now to look deeper into this, but it might be worth to look at the differences between i18n_taxonomy and entity_translation, the possible combined and standalone use of them to get them fully working with tmgmt. Otherwise, maybe a note in the documentation might be helpful to warn others that try to get it working without i18n_taxonomy.

Let's see if this helps.

Hmm.. Tests fail because of fatal "Call to undefined function tmgmt_translator_load()". I saw this error on my local when tried to run TMGMT tests on a Drupal installation having no TMGMT enabled. Not sure how to fight this...

A bit improved patch.

It makes that both "Source Language" and "Target language" filters use {entity_translation} table for the source language conditions.

This is works for me