Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The field language option may cause duplicate results when field language fallback is enabled. In this case it would be useuful to be able to specify one (or more) language to reduce them. Currently the delta field column is exposed for multiple fields. A possibile solution for this use case is exposing also the language column for translatable fields, which would be also consistent with the core EFQ implementation.
Comment | File | Size | Author |
---|---|---|---|
#33 | filter-for-field's-language.jpg | 29.84 KB | calculus |
#22 | views-1515156-22.patch | 1.86 KB | dawehner |
#14 | views-1515156_expose_field_language-14.patch | 1.97 KB | steinmb |
#5 | views-1515156-5.patch | 2.74 KB | fabsor |
#1 | views-1515156-1.patch | 2.64 KB | plach |
Comments
Comment #1
plachHere is a patch defining field, filte, argument and sort handlers field language column. Actually the first three are inherited from the locale language handlers. The patch also a fixes a small bug for the locale langauge field handler.
Comment #1.0
plachUpdated issue summary.
Comment #2
plachRelated issue #1330332: Entity translation: Views field language filter.
Comment #3
bojanz CreditAttribution: bojanz commentedI think this would make sense.
I have a question though: currently we also have the language selector on the field settings. Is it not confusing to do both?
I understand that this is for when the join actually happens (and I'd love to move to a world where it never happens :P), but the users might find the duality confusing. How do we solve that?
Comment #4
plachCorrect me if I'm mistaken but if I have understood the code right that setting applies only for multiple fields, right? What about moving it under the multiple fields settings?
Comment #5
fabsor CreditAttribution: fabsor commentedWe might want to separate the bug fix into it's own issue. There was another problem with the handler:
It should be $this->options not $this->$options
I will just go ahead and post an updated patch here for now, even if it's not really directly related.
Comment #6
plach@bojanz:
Any feedback on #4?
Comment #7
marcoka CreditAttribution: marcoka commentedyes fabsor, i found that bug today. you know if there is an issue that fixes these wrong object access parts
Comment #8
dawehnerAs the other patch is already committed we can do some nitpicking because there is a need for a rerole anyway: for 'table' and 'field' should not be needed here.
In general this looks fine.
Comment #9
cossimo CreditAttribution: cossimo commentedWhat is the status of this?
I have a similar (possibly the same) issue; however, from what I've seen, the duplicates result regardless of whether Language Fallback is enabled in Entity Translation. I've created a view containing an unformatted list of fields, and filtered it on published status, a particular content type, and a date field. For any given node represented in the results, the view seems to return a duplicate for each tranlatable field in the node's content type, multiplied by the number of languages the node is tranlated into.
Any help or direction on this issue would be greatly appreciated. And if this isn't the appropriate place to post this issue (or if more detail or an export of the view is needed), please let me know.
Thanks,
Chris
Comment #10
cossimo CreditAttribution: cossimo commentedI'm thinking of posting #9 as its own issue, but would like some clarification first. I have posted significant detail about this duplication problem under a similar issue posted for entity translation: http://drupal.org/node/1330332#comment-6134296. Please take some time to give me some feedback about whether I have a real issue or whether I'm configuring something incorrectly, and further, whether I should post this issue under Views or Entity Translation. (plach, I would really appreciate your input since you've been posting about similar issues both for Views and Entity Translation.)
Thanks for your help!
Chris
Comment #11
klonos@christopherostrom: ...I believe you're on the right issue Chris.
Comment #12
steinmb CreditAttribution: steinmb commentedI see duplication as soon as I try to sort by a translated field. No entity translation enabled. When I look at sql created by views can I see the problem. The sql. below lists terms from taxonomy vocal called area without translated field sorting and causes no duplication of listet terms.
But as soon as I add sort by translated field I get:
Edit: Also tried the patch in #5 but it does not address the problem.
Comment #13
plach@steinmb:
Didi you add a field language filter after applying the patch and clearing views cache?
Comment #14
steinmb CreditAttribution: steinmb commentedGood morning
Retested, what confused me was content language vs $title_short_language, correcting this and the duplication was gone! :) Some of the patch was already part of HEAD so we need to reroll.
Comment #15
cossimo CreditAttribution: cossimo commented#14 worked for me.
Comment #16
wiifmCan also confirm #14 worked for me. Would love to see this committed.
Comment #17
bojanz CreditAttribution: bojanz commentedLet's get this in.
Comment #18
klonosWorks here too! Thanx ;)
Comment #19
mErilainen CreditAttribution: mErilainen commentedWorks as described
Comment #20
dawehnerYeah it indeed looks perfect, committed to 7.x-3.x
If someone wants to rerole the patch feel free to to that, but at some point someone else will do it.
Comment #21
klonosGreat news! Thanx Daniel ;)
Comment #22
dawehnerHere is a patch for that.
Comment #23
dawehnerNothing spectacular so let's get this into d8.
Comment #25
chriscalip CreditAttribution: chriscalip commentedDoes this mean that we have to add filter field language for every single field instance in the query?
Or do we put in a random field as the field language filter?
For an optiomal user experience why not just have :
Advanced->Field Language:Current user's language
working correctly?
Comment #26
cossimo CreditAttribution: cossimo commentedNo, filtering on a single field's language works fine.
Comment #27
chriscalip CreditAttribution: chriscalip commentedI updated my comment on #25; i am pleasantly surprised with the speed of people commenting on this issue :)
Anyways: what cossimo missed:
For an optiomal user experience why not just have :
Advanced->Field Language:Current user's language
working correctly?
Comment #28
chriscalip CreditAttribution: chriscalip commented#26 this is not true.
I am still experiencing duplication on the result set. Please don't just disregard this action; one of the previous RTBC'ers of this issue also admitted on https://drupal.org/node/1330332#comment-6514860 that he had to do extra actions to get the desired results.
Well i also did those extra actions and it did not get the desired result.
With my experiences I do not agree on the RTBC or fixed status of this issue. This is still an active issue;
Comment #29
chriscalip CreditAttribution: chriscalip commentedsee #28
Comment #30
chriscalip CreditAttribution: chriscalip commentedi did not test 8.x but i encountered the active bug on 7.x branch.
Comment #31
chriscalip CreditAttribution: chriscalip commentedMy experiences with the issue queue leads me to believe that this is another issue entirely.
Hence I am closing this down and creating a new issue.
https://drupal.org/node/1832892
Comment #33
calculus CreditAttribution: calculus commentedI applied patch #22 but there are no form fields for entering filter values. Only tickbox for exposition is available.
Comment #33.0
calculus CreditAttribution: calculus commentedUpdated issue summary.
Comment #34
MXTThis #26
does not work in my case, and #25
is the only working solution for my case (taxonomy based views + entity translations + sorting exposed filters)