Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
Attached patch allows to filter by the language of a field content.
This is what I need atm. - but I'm sure there's plenty other stuff we have to consider for field based translations.
(My current issue is that the output is duplicated because I can't filter for the needed language.)
Probably related issues:
#987478: Field language is not properly handled
#936196: Don't use entity_load to display fields
#936196: Don't use entity_load to display fields
This patch has to be considered as slow & buggy since I've just hacked it in ;)
Comment | File | Size | Author |
---|---|---|---|
#16 | translations.patch | 2.17 KB | bojanz |
#13 | 1006176.patch | 9.47 KB | bojanz |
#12 | 1006176.patch | 9.41 KB | bojanz |
#11 | 1006176.patch | 8.53 KB | bojanz |
#10 | 1006176.patch | 8.1 KB | bojanz |
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedPartially unrelated: how would you handle your use case with entity_load back in the picture (per #1002744: Use entity_load for fieldapi field handlers)?
We really need to get all this right before an alpha...
Here's what plach said about field translations:
Comment #2
das-peter CreditAttribution: das-peter commented@bojanz: Oh, just discovered that I linked two times to the same issue instead of the one you mentioned ;)
I think no matter what we use to load / display the entity - the data have to be filtered before.
plach's suggestion makes absolutely sense and I'd like to have such a solution.
Unfortunately I'm heavily driven by a current project with a very aggressive schedule. Means, I've to get done my tasks. And the first solution I was able to create was a language filter for fields.
And because I hope it's usable for others or at least a seed for further development I decided to post it here.
Instead a standalone filter I could imagine to but these options in the field configuration itself - or maybe even provide a global setting per view / display.
I'd like the concept of field based translation very much and my gut feeling tells me this will be a very common way to serve multilingual sites. Thus I'd like to help get this done - but I hope for some advices / concepts.
Attached a slightly changed patch.
Comment #3
bojanz CreditAttribution: bojanz commentedAgreed. However, my gut tells me that this can't be done right without entity_load.
The translation module has it's own logic for determining the current language, so our filtering by node language might be totally wrong, no?
If we load the "de" translation by sql, and then entity_load and translation load "en" and decide to use that one, we have a problem.
Of course. The most useful part of it is the fact that it started this discussion. I'm grateful for both.
Comment #4
das-peter CreditAttribution: das-peter commentedSince my patch is just about getting rid of the duplicates I think this could be done with a "GROUP BY node.nid" and the entity approach. This way we could bring both together.
But frankly speaking I've totally now clue how Views and grouping works - always when I turn it on an check the query then it's a wtf for me :)
Comment #5
Remon CreditAttribution: Remon commentedComment #6
bojanz CreditAttribution: bojanz commentedI worked on this tonight.
However, I'm not allowed to post patches at 3AM.
So, see you tomorrow.
Comment #7
bojanz CreditAttribution: bojanz commentedHere's my patch.
One general change you'll notice is that ***CURRENT_LANGUAGE*** now gets replaced with $language_content->language, and not $language->language.
This is a D7 change. In D6, $language meant "active language". In D7, $language means "interface language" and $language_content means "content language".
The main part of this patch adds a field setting allowing you to specify the field language.
The setting is only visible and taken into account when there's a registered translation handler for the given entity, and when field is marked as "translatable".
So, if there's no project/translate (or a non-existing alternative) installed, there's no setting.
You might wonder why I went with the field setting approach.
Since language is now a per field column, adding one language filter per field would start to look ridiculous & repetitive.
On the other hand, we can't add it to Query settings, since the setting should be shown only if we are querying a fieldable entity with a registered translation handler, and views currently knows nothing about entities.
Of course, without entity_load() there's no language fallback.
Also, this only works right if all fields have the same language settings, because of our entity-building-hack. If you want to display one "en" field and another "de" field, it won't work without entity_load() or without adding a hack that clears the field_language() static cache (as mentioned in #987478: Field language is not properly handled)
Comment #8
plachsubscribing
Comment #9
bojanz CreditAttribution: bojanz commentedWe have a fatal flaw in the patch above. This needs to be a per entity,not a per field setting.
field_language() allows you to select one language per entity for fields.
So if someone selects English for Field A and German for Field B, it won't work as expected.
I now have no idea where to put this setting...
Comment #10
bojanz CreditAttribution: bojanz commentedNew patch. Completely untested.
Comment #11
bojanz CreditAttribution: bojanz commentedActually, that was the old patch :D
Comment #12
bojanz CreditAttribution: bojanz commentedFinal, tested patch.
Also fixes a notice in views_handler_field_field::query() introduced earlier tonight.
Comment #13
bojanz CreditAttribution: bojanz commentedDereine reviewed the patch on IRC.
And I changed another comment.
Comment #14
dawehnerCommited to the 7.x branch. Awesome.
We made a lot of progress in the last days.
Comment #16
bojanz CreditAttribution: bojanz commentedHere's a small followup.
It looks like a style cleanup, but actually efq_views won't work without it (I could work around it, but this is clean)
Comment #17
bojanz CreditAttribution: bojanz commentedI've included these changes in my patch at #1041340: 'Field Language' in 'Query options' missing "All languages" option.