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 ;)


bojanz’s picture

Partially 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:

In D6 we support CCK multiple fields allowing to specify which deltas have to be selected for display: field language should be handled the same way, if possible, allowing to select which languages retrieve. We don't need to load all languages everytime, in a common scenario in which every content is properly translated, we just need to pick up one field translation for each field (current language or LANGUAGE_NONE). This should allow to have ranged queries without too much hassle.

das-peter’s picture

@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.

bojanz’s picture

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.

Agreed. 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.

And because I hope it's usable for others or at least a seed for further development I decided to post it here.

Of course. The most useful part of it is the fact that it started this discussion. I'm grateful for both.

das-peter’s picture

Since 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 :)

Remon’s picture

Component: Code » fieldapi data
bojanz’s picture

Assigned: Unassigned » bojanz

I worked on this tonight.

However, I'm not allowed to post patches at 3AM.
So, see you tomorrow.

bojanz’s picture

8.1 KB

Here'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)

plach’s picture

Issue tags: +translatable fields


bojanz’s picture

We 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...

bojanz’s picture

8.1 KB

New patch. Completely untested.

bojanz’s picture

8.53 KB

Actually, that was the old patch :D

bojanz’s picture

9.41 KB

Final, tested patch.
Also fixes a notice in views_handler_field_field::query() introduced earlier tonight.

bojanz’s picture

Status: Needs review » Reviewed & tested by the community
9.47 KB

Dereine reviewed the patch on IRC.
And I changed another comment.

dawehner’s picture

Status: Reviewed & tested by the community » Fixed

Commited to the 7.x branch. Awesome.

We made a lot of progress in the last days.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

bojanz’s picture

Status: Closed (fixed) » Needs review
2.17 KB

Here'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)

bojanz’s picture

Status: Needs review » Closed (fixed)