Entity Translation Filter is a minimalist approach of making multilingual
content managed via entity translations correctly selected / filtered in views
(and later probably other content listing queries).
The module cares a.t.m. cares automatically for correct translation selection
for node based views when using entity_translation.module for managing
The current approach employs hook_rewrite_query.
Later solution might include a dedicated and explicitely addable views filter.
The filter selects only entities, which:
* are language neutral (later controllable via switch, see ToDos)
* have their original language version matching the current display language
* have an entity_translation record matching the current display language
* Entity Translation
* Currently (2012-01-13) there does not seem to be other similar modules.
The aim is to drive this towards a first generally appropriate solution fast within this sandbox module and then ideally to move the code over to Entity Translation itself.
There are currently a lot of possible improvements.
First in line:
* The fields are given in the query conditions in a very dirty way - because the proper, documented way (just using the field alias returned by the queries' addField method) throws SQL Exceptions galore (Database API wisdom desperately needed here! <:)
* Let's discuss whether this is the correct problem, the proper solution and the right direction to move in, or whether we should instead (or additionally?) do this via a explicit views filter (would work only for views, though).
* Add configurable options:
* switch to selectively include or exclude language-neutral entities
* switch to override filter for admins (via current user's permission)
* switch to filter out unpublished translations (entity_translation.status=1)
* switch to filter out stale translations (entity_translation.translate=0)
* Add dedicated and explicitely addable views filter to do the same job
selectively applicable for each view display
* consider and test broader application of rewriting beyond just views
* make conditional statement "$base_table == 'node'" for triggering rewrite
generic and entity type agnostic, by somehow (?) making a connection
between the queries' basetable, the associated entity type, and
ET's translation support for that specific entity type. puh.
* cache $base_field determination
* get rid of necessary but very dirty workaround in language conditions:
tablealias.fieldalias / tablealias.fieldoriginalname
* make status=published on translations automatically matching a
status=published condition of (known) base table(s)