| Project: | Entity Translation |
| Version: | 7.x-1.x-dev |
| Component: | Views integration |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
With the normal translation there is a filter that checks the languages of the node. So you could for example only display the nodes that are in the users language.
With Entity translation this filter doesn't work because the node is in 1 language en the field are translated. The problem now is that if a node is published but no translation is provide a message will be displayed that the node is not translated or it will show the node but only the fields that can't be translated.
By turning on 'Enable language fallback' the node will be displayed in another language but this is an overall setting and maybe you just want this for certain node types or views.
So a filter that can be set per view would be more flexible. Maybe something that checks if a translation for the node is added?
Comments
#1
possibly related: #1305770: Entity Translation shows all translation if using a contextual filter and #1346242: Duplicates in views if entity translated using entity translation
#2
here is my use case which needs a field
content type entity translated
with title_field and image field both entity translatable
view using content:fields
if my view gets nodes which all have translations the view works great using no filter and settings "Query settings:Settings Distinct" and "Field Language:Current user's language" and on the field settings I check "hide empty fields"
when one or more nodes don't have translation the view gets messud up if I add a field which is never empty for all language like NID, Edit Link etc
using a filter like "title_field NOT EMPTY" or "image field NOT EMPTY" does not work either and views shows all nodes, some nodes might have only NID or Edit link displayed since there is no real translation of the tile or image ...
thus a views field language filter would be most useful in such cases
a temporary workaround would be to user hook_views_query_alter(&$view, &$query) OR hook_views_pre_render(&$view) or user Views PHP for filtering the output
#3
fyi: Filter views by ET translation language
I'm planning to implement (and contribute via patch) a views filter that filters the selection of entities in views for selecting only entities that have a original version or translation in the current display language.
Please give your input at http://drupal.org/node/1402692
#4
A sandbox module for filtering content queries for Entity Translation content by proper language has been created, see http://drupal.org/node/1402692#comment-5468944
#5
#6
I was rather thinking about something like what I've attached. This filters on the language field of the entity_translation table. So as long as you haven't created a translation it doesn't exist in this table and you can filter on it.
Currently the patch only works with the node table but see for example field.views.inc to make it more generic to work with all entities. Will continue to work on this.
#7
That's cool, too, Jax. I think _both_ your filter in #5, using views' filter alteration, and my filter in #4, using query rewrite (configurably broadened to any query in Drupal) should be included into ET. And both filters need some work to cover non-node entities, too. Perhaps we can join forces, and perhaps the ET maintainer can provide some opinion on this and how/in what form to get it into ET (blink-blink towards Daniel ;)
#8
Hi Daniel, I'm definitely in favor of having built-in Views support, unfortunately I could not follow your progress yet. Would you mind to summarize the current status in the other issue, if anything changed from http://drupal.org/node/1402692#comment-5468944?
Obviously we need to support any entity.
#9
Jax, any updates on this? Would love to be able to create a view that shows me all files (images) that are untranslated. Thanks!
#10
@BarisW The patch provided in #6 works so I'm not sure what you want.
#11
@Jax:
I need it to filter images (files), not nodes. That's why I was wondering if you got any further (as you mentioned you were continue working on it)?
#12
Oh, I guess I did say that. I'll try to do that then in the next couple of days.
#13
Cool, thanks!
#14
Great, this seems to work... would love to see it committed!
#15
I think this particular use case should be solved by Views, since it's basically fully supporting the core Field language API. What @danielnolde linked in #3 is a different issue that belongs to ET.
See #1515156: Expose the field language column for translatable fields.
#16
Marked the following as duplicates of this one:
#1305770: Entity Translation shows all translation if using a contextual filter
#1346242: Duplicates in views if entity translated using entity translation
#17
Actually postponing to see if the patch linked above is accepted in Views.
#18
I've updated the patch to support all the entity types since I said I would do that. Is completely untested.
#19
I tried to using the patch to show a glossary of node types with a thumbnail, title and subtitle in both a grid & table
.. using all choices in "Entity translation: Language" (users language, german or english) ... sadly it failed and everything is still doubled
see img
#20
#21
Just to follow up on what stevieb wrote in #19, my experience was the same. The patch does expose the entity_translation table as Views filters; however, this doesn't help with filtering out duplicates that result when the fields of a node are translated. From my experience, when a node has X translatable fields, and the node has been translated into Y languages, XY duplicate results will appear for that node. (This is the case regardless of whether Language Fallback is enabled or not.) Setting the "Query settings" to "Distinct" will prune the results down some; however, at best, I get a duplicate result for every translated field in the node.
This particular issue is different from the original issue in this thread, which focuses more on gracefully handling untranslated nodes and fields, and as such should probably be submitted as its own issue. However, it seems so fundamental, that I would just like to make sure I'm not missing something before I submit it as its own issue.
That is, is there a tool, filter, or strategy I'm missing that will allow me to filter a result set in such a way that multiple translated fields associated with a single node do not result in duplicate results for that node? And if there is no way to filter results in this manner, where should this issue be submitted? Under the Views project or the Entity Translation project?
I have attached an export of the view. The version of Entity Translation I am using is 7.x-1.0-alpha2 (6-16-12), and the version of Views I am using is 7.x-3.3+173-dev (6-17-12).
Thanks very much for your consideration and help with this!
Chris
#22
Yea, I had that same problem. The following piece of code may not be the best way to do things but seems to solve it for me. This would go in a hook_views_query_alter() function. It's hardcoded to only work for views that display one type of node but can be modified to work for multiple node types.
<?php
if ($view->base_table == 'node') {
if (!empty($view->filter['type']) && count($view->filter['type']->value) == 1) {
$node_type = reset($view->filter['type']->value);
$translation_type = variable_get('language_content_type_' . $node_type, 0);
if ($translation_type == ENTITY_TRANSLATION_ENABLED) {
global $language;
$languages = array(LANGUAGE_NONE, $language->language);
$language_join = array(
'field' => 'language',
'value' => $languages,
);
foreach ($query->table_queue as $table_name => $table) {
if (strpos($table_name, 'field_data') !== FALSE) {
$query->table_queue[$table_name]['join']->extra[] = $language_join;
}
}
}
}
}
?>
The issue seems to be that views sometimes uses entity_load to get field definitions, but other times just JOINs the field table directly on and retrieves data that way.
#23
subscribe
#24
@creando sensaciones: Stop subscribing, start following
#25
@torpy, re: #22, from what I've seen so far, this works great! Thanks so much!
C.
#26
Do i undestand right that #22 is the best solution so far, for filtering views fields by entity language?
If so, then I don't know how to implement the code provided in #22, sorry.
A patch or steps to get this working would be great, thanks!
#27
Same here. I've tried with template.php, but cant get this to work.
#28
You will need to put the function in a custom module. I can post mine for you tomorrow for reference.
C.
#29
Ok. That would be helpfull I think.
#30
Very sorry... This slipped my mind. Attached is my custom module. (It may not meet Drupal coding standards, but it works.)
C.
#31
Just to be clear about the main topic of this issue: Entity translation: Views field language filter.
I use entity translation on groups (which seems the only way for OG to translate groups)
My issue is that I want to filter groups in views, by current user language.
When I select Content: Language (in Current user's language) the view doesnt show any results, doesn't show the groups that are translated.
As for the module mentioned in #30, I installed it but have no idea what i should see or do, i don't see any change in settings or views output.
Can someone please assist me with this issue, it seems that this thread is the only one that handles views language filter for entity translations.
#32
Yuri:
Per recent activity addressing this problem in Views, the following patch is a better route to take for resolving this issue: https://drupal.org/node/1515156#comment-6511750
After applying the patch, the language(s) for any translatable field can be used as filter criteria for the view. It works very well, though in some instances, I've also had to check "Distinct" under Query settings.
C.
#33
Yes, that patch over there has been committed to the Views project so we don''t need this anymore.
#34
Is there a patch/fix for #21 problem, other than #22 manual override?
#35
The fix is in the Views issue linked above: you can specify a filter for a particular language as you would do for the field delta.
#36
Thank you.
#37
What worked for me:
Greetings